Some thoughts about Git

Not too long ago I decided to start writing a book about distributed version control. I was originally going to focus on Mercurial (Hg) because it’s quite good and of the two leading systems it was the only one that ran on every OS (because it was written in Python). The fact that it could also run under Windows meant that I could help spread the word about distributed version control to more people, and it slightly increased the chance that I might actually make some money in the process.

There was just one problem: Linus was right.

“Hg is pretty good, but Git is better.” - Linus Torvalds

When I heard him utter those words in his talk to the folks at Google I took them with a grain of salt. Almost every project owner believes that their software is “better” than the competition, especially when they’re so similar, but it turns out that it wasn’t hubris on his part. When you sit down and compare the functionality Git simply lets you do more.

I had actually started writing the book about Hg but time and again I found myself confronted with something that was either easier to do in Git, or simply not possible in Hg. It happened enough that I decided that I didn’t want to keep writing about, and arguably helping, out a product that I not only wouldn’t choose to use myself but also felt was dramatically inferior from a usage standpoint.

And then I joined the Git mailing list. Linus mentioned that it had a high signal to noise ratio but… holy shit. I have been on a lot of mailing lists for open source projects over the years and I have never seen anything like this. Almost every e-mail is a patch, or a good discussion of a patch, or a good discussion of some new feature and how to go about implementing it. Currently, one of the topics they’re discussing is how to allow people to push to a Git repo based on GPG keys stored in, or accessible by, Git. What’s amazing is that it isn’t just one or two people going back and forth or someone trying to proclaim the “one true way” to do things. It’s exactly what you would expect if you took a bunch of smart geeks, stuck them in a room, and watched them all work together to solve some common problem. That alone is impressive, but when you combine that with the fact that it’s a pretty high traffic list and you’ve got a lot of really smart people pushing a tool forwards at an incredible pace.

Now, all is not sunshine and roses in Git land:

The documentation is actually pretty good, but when you want to do a specific task and don’t know the Git specific terminology for it it can be a little difficult to find what you need, and sometimes the commands take a dizzying array of options and could really do with more examples. That works out well for me, because it’ll be all the more reason for people to buy my book, but it’s obviously not great for attracting new users. I still think that, for most use cases, Darcs does a better job than anyone at making it easy to ferret out what command you need to accomplish a task.

Git is a lot like C. It’s incredibly flexible and powerful but it is also incredible flexible and powerful. If you want to shoot yourself in the foot Git will point you to the gun rack and show you how to load the bullets.

Under the covers Git is a collection of small C apps surrounded by shell scripts, Perl scripts, Python scripts…. whatever the author chose to get the job done. From a usability standpoint this is irrelevant. Calling “git foo” is going to work just as well regardless of what foo was written in and will have no impact on the user, but I’d personally prefer to hack on a project that was all written in one language.

It also means that the msysgit team has a lot of work ahead of them in trying make it install easily under Windows. If you’d like to see git working under Windows, and are familiar with coding for Windows please check these guys out and see if there’s anywhere you can help out. Even just taking on a little task here and there is something that would be greatly appreciated. Part of me wonders if it wouldn’t be better to just port everything in Git to C.

I think that if the Git book goes over well I may go back and retool it for Mercurial, but in the meantime I have to agree with Ted Tso:

“…the main reason why I’ve come out in favor if Git is that I see its potential as being greater than [that of] Hg, and… in the long run I think it has ‘more legs’ than Hg…”

Just to be totally up front. Ted did have some complaints about ease of use and documentation, but I think that since his post came out Git has made some really significant improvements in those areas.