Some thoughts about Git February 4, 2008
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.
P.S. For anyone who things I should improve the docs instead of bitching
about their limitations and profiting off their lack by writing a book
I would say, “chill”. I plan to submit some documentation patches and
the book will be GPL v2 licensed so people will be free to grab
anything they want from it, although the book is taking a task-based,
cookbook style approach which isn’t really appropriate for man pages,
but may be useful on the wiki. Also, I probably won’t see much, if any,
profit from the book. ;)
Leave a Reply