Exactly one year ago today, I wrote about Git, Mercurial, and Bzr. I have long been interested in VCS, and looked at the three main DVCS systems back then.
A Quick Review
Mercurial was, and for the moment, remains, my main VCS. Bzr remains really uninteresting; I don’t see it offering anything compelling that Mercurial or Git can’t do. My Git gripes mainly revolved around its interface and documentation. Also, I do have Windows people using my software, and need a plausible solution for them, even though I personally do no development on that platform.
Ted Tso wrote his own article in reply to mine, noting that the Git community had identified many of the same things I had ans was working on them.
I followed up to Ted with:
… So if Ted’s right, and a year from now git is easier to use, better documented, more featureful, and runs well on Windows, it won’t be that hard to switch over and preserve history. Ted’s the sort of person that usually is right, so maybe I should starting looking at hg2git right now.
So I guess that means it’s time to start looking at Git again.
This is rather rambly, I know. It’s late and I want to get these thoughts down before going to sleep…
Looking at Git
I started at the Git wikipedia page for an overview of the software. It linked to two Google Tech Talks about Git: one by Linus Torvalds and another by Randal Schwartz. Of the two, I found Linus’ more entertaining and Randal’s more informative. Linus’ point that CVS is fundamentally broken, and that SVN trying to be “a better CVS” (an early goal of svn, at least) means it too is fundamentally broken, strikes me as quite sound.
One other interesting tidbit I picked up is that git can show you where functions have moved from one file to another, thanks to its rename-detection heuristic. That sounds really sweet, and is the best reason I’ve yet heard for Git’s stubborn refusal to track renames.
The Landscape
I’ve been following Mercurial and Darcs somewhat, and not paying much attention to Git. Mercurial has been adding small features, and is nearing version 1.0. Darcs has completed a major overhaul both of its repository format and internal algorithms and is nearing version 2.0, and appears to have finally killed the doppleganger (aka conflict spinlock) bug for good.
Git, meanwhile, seems to have made strides in usability and documentation in its 1.5.x versions.
One thing particularly interesting to me is: what projects are using the different VCSs. High-profile projects now using Mercurial include OpenSolaris, OpenJDK (Java 7), and Mozilla’s projects. Git has, of course, the Linux kernel. It also has just about everything associated with freedesktop.org, including X. Also a ton of Unixy stuff.
Both Mercurial and Git communities are working on TortoiseHg/TortoiseGit types of GUIs for Windows users. Git appears to have a sane Windows port now as well, putting it on pretty much even footing with Mercurial and Darcs there. However, I didn’t spot anything with obvious Windows ties in the Git “what projects use git” pages.
The greater speed of Mercurial and Git — even for pushing and pulling small patches — likely will keep me away from Darcs for the moment.
Onwards…
As time allows (I do have other things keeping me busy), I plan to install git and work through some tutorials and try to use it in practice as much as possible, to get a good feel for it.
Future
It is beneficial to be using a VCS that is popular, though that is certainly not a major criterion for me. I refuse to use SVN because its lack of distributed functionality makes it too unproductive to be useful. But it looks like Git is gaining a lot of traction these days, especially in Debian circles, which also makes it more interesting.
I notice that Ted did convert e2fsprogs over to git as he said he might, incidentally.
At my day job, we store all of our source in a central SVN repository, since that was the cool thing to do back in the day.
Personally, I’ve been on the lookout for a good distributed complement to our SVN since ICFP 2005 (when I saw Audrey Tang demonstrate svk). I’d already been burned by enough branch management and switching to understand the value. Unfortunately, svk turned out to be too buggy, inflexible and heavyweight for what I wanted. When I ended up going off and working on a complicated personal branch, svk was better than nothing, but it didn’t always work right and it was too much work to use for smaller bits of local development.
Recently, I ended up trying git (and, most importantly git-svn) and it seems to be everything I want. The svn integration is top-notch (which surprised me because I thought svk would do the best there since it is built on SVN). Pushing and pulling from our central SVN is as seamless as I could want. “git svn rebase” and “git svn dcommit” let me reconcile my local, incremental changes with the central linear history, without making mistakes (which was the worst part of using svk – if a merge conflict wasn’t resolved just right pushing back to the repository might create trash).
git is still slower than I’d like sometimes (I think I’m using the wrong commands for some operations) and I’m not yet happy with the options for managing multiple git repositories (I’d like to move code back and forth between my laptop and one of our fast servers and I just haven’t gotten that to work right), but it is still a big step forward from what I had before.
As a Haskell programmer, I feel a little guilty I’m not using darcs, but, for the moment, git-svn is what works for me.
Git’s capability in the analysis of data movement is really what makes it attractive for me (along with its performance). My major gripes, however, are the (really) messy sources, the bad (virtually non-existing) architecture documentation, the geeky terminology, and the somewhat unorganized interface. So much for my rant for today.
“Bzr remains really uninteresting; I don’t see it offering anything compelling that Mercurial or Git can’t do.”
bzr has the concept of “foreign branches”; write a plugin to make it interoperate seamlessly with your revision control system of choice. For example, bzr-svn allows you to use bzr on a remote svn repository; unlike git-svn, there are no special, additional command, it “just works”. Read-only version for git and hg exist. With all the different systems around, that could be a killer feature.
Both git and Mercurial have read-write support for foreign branches in different formats. I think git’s is probably more advanced, though. From what I have seen from personal experience in Mercurial, and have read about Git, both are easy to use.
Git’s windows support is really lacking. It runs on windows, but having to use a customized shell and terminal (msys) to be able to do anything useful is not exactly what one understands as a windows application. It’s only slightly better than using cygwin and, besides that, the mingw port isn’t fully integrated in the main branch…
The git cheat sheet is incredibly useful for people who are new to git. It can be found here: http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html
At OLPC (where we use git exclusively), it’s printed out and hanging on a wall in the main room.
One really sweet feature git gained in the last year and which is probably not advertised much, is “git add -i”, which is interactive tool to add only some changes for commit ala “darcs record”.
I’ve been writing about Git a bit lately.
I’ve decided to switch some of my Debian work over to it to start with, as well as some of my other projects.
Although I was thoroughly frustrated with Git a year ago, now I am quite pleased with it. What’