Dragged onto the Gitwagon

For a very long time, I've spewed vast amounts of spite and vitriol in the general direction of Git, a distributed version control system (DVCS) that has more obnoxious worshippers than Justin Bieber.  People tend to have one of two instinctual reactions to that type of religious evangelism:   they either hop on the bandwagon or run the other way in terror.  I basically took option #2.

I have, however, had practical, rational reasons for not jumping on Git.  For most things I work on, I feel more comfortable having a central, authoritative repository for the code.  Git doesn't work that way; all repositories are equal, and working with a centralized development model seems a lot more difficult than it should be (or needs to be).  Git also has no way to check out (i.e., clone) a repository without snarfing its entire history -- every branch, every commit, every file that is or ever was a part of it.  This makes Git a poor choice for one specific task I use source code management (SCM) for most often:  maintaining RPM packages.  When I import an RPM, one of the things that gets imported is the source tarball.  Each upstream release is also checked in after the old tarball is removed.  With CVS, this only takes up space on the master server; with Git, every clone would require the same amount of space.

About a week ago, the folks at Adaptive Computing announced that they were going to move TORQUE, the resource manager we use for all our clusters, from Subversion to GitHub (and thus git).

I cried.

Well, okay, not really.  But I wasn't too thrilled.

That said, I went right away and created a GitHub account.  (Unfortunately, "mej" was taken; fortunately, "kainx" was not.)  I spent much of the subsequent week learning as much about Git as a I could in the small amount of time allotted.  I was able to get it set up to pull from the SVN server prior to the upstream migration, and I was able to play around a little bit with branching and patching.  Thankfully Jared knows Git and was a big help.

So far, I definitely think Git has some advantages.  Being able to commit locally is, indeed, quite handy.  So is being able to maintain my own branches and send along merge requests for changes I want applied upstream.  But it's still incredibly complex, and I'm still trying to make it work the way I want it to.  Overall, though, I think it will make my tasks of maintaining multiple patchsets simultaneously easier.  I just need to wrap my brain around all its nuances and intricacies so I better understand what it's doing behind the scenes....