Over the last few days I’ve been experimenting with distributed version control. I’ve finally settled on git. My large projects (Bugdar, namely) will remain in Subversion for the foreseeable future because I don’t want the hassle of converting. However, one of the drawbacks of SVN is the fact that it needs a dedicated svnserve or Apache2 DAV. Most web hosts offer neither of these, which will make it impossible for me to publish my smaller works. In a few months when my current Subversion server will be taken offline forever (because I will no longer maintain it at college) this will cause problems. This left me with two options: create Sourceforge.net projects for each small project (which I didn’t want to do as some may die very quickly, others are too small and not worth it, etc.), or find a new version control system that didn’t require special servers. Hence, I went shopping for a version control system that works over plain old HTTP.
First, I tried Bazaar. It was okay. Nothing spectacular, however. And it seemed rather immature. SVK sounded interesting but it still relied on the SVN repository layer so it was done before it got started. I then thought about creating a Ruby-based CGI WebDav implementation and then adding a layer on top of that with the SVN SWIG bindings. However, I ultimately decided against this because it sounds like a total pain in the a$$ to maintain the SVN part of the equation (though I still may write the WebDav Ruby CGI as it sounds like a fun challenge).
So I was back at square 0. Then I decided to look at git. I briefly glanced at git in my searchings before but I was turned off by the command set. But I finally went back and had a thorough look. And I’m now using it to manage a new project I’m working on (more on that in another post).
Using git is straightforward (for most things).
The only feature I wish I had was the ability to do the equivalent of “svn revert” on specific files instead of “git reset –hard” on the entire working copy. I also miss incremental revision numbers. But I’ll live. Because git is fast, and doesn’t get in your way at all. It makes perfect sense.
And git has some amazing features. The first of which is a compile-instantly and an install-without-being-root installation. Then there’s the whole notion of the “index” (or a staging area for commits). I like this a lot as it forces me to be more careful with what I commit. Also, the two built-in GUI commands (gitk and git-gui), while unattractive, are very useful and it’s great they come out-of-the-box without any work. But my favorite thing is definitely the ability to go back and edit the last commit! It’s fantastic to be able to fix a mistake without having to make a whole separate revision.
So I’ve been using git locally for a few days now, and I decided it would be a good idea to try push-ing it to bluestatic.org to make sure that public repositories will actually work! After many, many failed attempts all I could get was this cryptic message:
bash: git-receive-pack: command not found
fatal: The remote end hung up unexpectedly
error: failed to push to [removed]
And then, by chance, and after a good 20 minutes of searching, I found this perfect answer on Google:
Many installations of sshd do not invoke your shell as the login shell when you directly run programs; what this means is that if your login shell is bash, only .bashrc is read and not .bash_profile. As a workaround, make sure .bashrc sets up $PATH so that you can run git-receive-pack program.
So I solved this error by simply creating a .bashrc file with this in it:
I thought I’d just write about this in hopes of helping others out.