In Praise of Git, the Greatest System Of Its Kind

It’s kinda funny because Linus likes to use a lot of tongue-in-cheek hyperbole. He called the CVS the devil, Subversion developers morons, and had some fun banter with Google engineers who use the centralized model in Perforce which he insisted can never work as well as a distributed model.

I’ve tried and failed to explain to the world what is special about Git. I was encouraged to see Linus himself have some trouble also. It’s not that I’m a failure, this thing is just hard.

But it isn’t so different from a lot of other hard to explain things.

Say you just learned Ruby on Rails, you made your first little Rails website in record time, and you’ve just got to tell your co-workers about this fantastic Ruby thing.

While you wait for Eclipse to start, it looks a lot less shiny today, you head over to the break room and attack your first target coworker. And as you launch into your first explanation to the incredulous, words fail you. How do you explain to the newly hired former J2EE consultant that not having config files and hard coding everything using a special convention is more flexible? Words fail because you sort of have to have been there and consumed enough kool-aid to see where these nut jobs were coming from. And they were right! Dead right!

How do you explain enlightenment?

Maybe you just learned Erlang and it’s your new hammer. Ready to convince your boss to let you try it in anger?

It’s hard to explain to somebody what a fun party it was because, well, if they weren’t there, they weren’t there. And if they weren’t there, they didn’t experience first hand all that fun. No enlightenment for them.

But I’ll try again. My first attempt failed, but I think I’ve learned better this time.

First I want to talk about SpongeBob.

There’s this episode of SpongeBob where his boss makes he and Squidward work 24 hour shifts at the fast food joint. SpongeBob can’t get enough of being a fry cook and pesters Squidward mercilessly for the whole night. “Hey Squidward, I’m cleaning the bathroom… at night!” “Hey Squidward, I’m polishing the tables… at night!” Or whatever.

And how many times have we seen some stupid blog meme like this: “Hey Internet! It’s Ruby program for… the Y combinator!” “Hey Internet! It’s a Perl program for… the Y combinator!”

Or maybe it’s a language: “Hey everyone, it’s a wiki… in Haskell! It’s a weblog.. in Haskell! It’s a stupid blog post… about Haskell!”

All these little toys flying around the Internet, and here’s where I try to get back on track. I’ve heard some folks cursing the fact that so much energy is being wasted on mere toys, when we could try and get some real work done.

I think something was lost with CVS and Subversion. Torvalds points out that in his not so humble opinion, CVS and Subversion are inferior to just passing around patches and tarballs. And here he isn’t being tongue-in-cheek. He really means that.

How could that be? When all you have is a mailing list and patches, even the core developers of a project have to communicate their code on a mailing list, and in little mail sized bits.

What’s outrageously cool about the whole thing, is real work degenerates into little memes.

“Hey look at this patch, it’s a new filesystem that twice as fast as the old one!” (see series of 6 patches)

“Hey, I increased your performance by 10% with this modification.” (Patch sent in reply to patch 2)

“Hey, that’s cool, but you missed a case and could corrupt unless you handle this.” (Patch sent in reply to patch 5.)

What I’m getting at is it’s that silly SpongeBob, “Hey Squidward!” behavior, but it gets real work done. Where CVS and Subversion go wrong is that they make it convenient for core developers to skip that step.

The core developers lose out on code review, and more importantly, on that stupid code banter. Stupid code banter is a fundamental human need.

Why would sane people post FizzBuzz implementations on the intarweb? Because code banter is required for human sanity. Once CVS and Subversion got popular everyone forgot the natrual way to bat code around, and had to turn to artificial drugs, Y and FizzBuzz.

Git comes from this guy and his friends who, in their isolated kernel world, never forgot about the fun of batting code around, and how you can harness it to get real work done. They saw early on that it’s 10 times more fun to review code before the flaws are petrified in in a subversion trunk. That’s the real lesson.

10 Comments on “In Praise of Git, the Greatest System Of Its Kind”

Hmm …
Now I’ve just upgraded my kernel and seen serious performance degradation in the piix ata drivers. What happened there? Some nice tools to actually identify where things were changed would be nice, along with tests. Discipline is not given by the tools. Sorry, blog filed in the circular filing bin.

At my workspace, we use perforce, and I review changes that are checked in passively. Works just as well, but isn’t really relevant to the discussion.

Recently, I’ve created a workflow around mercurial. I use tailor to automatically sync p4 changes from everyone else into an online mercurial repository, and I’ve got a simple tool on top of mercurial queues that pushes my changes back to perforce.

Yesterday, I was working from home and created somewhere around six changesets for new features (and a little code cleanup, etc…). My connectivity went down while I was in the middle of all this work. I didn’t notice.

Centralized revision control makes no sense in any context. Conceptually, there’s nothing you can do with centralized revision control that you can’t do with decentralized tools, but the converse is most definitely not true.

I’ve personally not used git (partially because it’s less interesting than mercurial, and partially because my package system won’t actually give me a build). I have used rcs, cvs, svn, perforce, gnu-arch, darcs, and mercurial extensively. Ten years ago I had people argue with me about how much better rcs on shared filesystems was than cvs for developer productivity. Ten years from now, centralized vs. decentralized will sound equally absurd.

I think the lessons from git do apply, for the most part, to other distributed version control systems. Still, Linus can claim to be the brainchild behind the whole thing, since the first really distributed system (BitKeeper) was based on conversations with Linus.

I agree that distributed VC is better than centralized, but your rag on CVS/svn is too much. When it was new, CVS was as world-shaking as git & co. are now, and you couldn’t have distributed VC without CVS’s innovations. Today, using CVS makes no sense; six or seven years ago, though, it was the market leader, and deservedly so.

It’s a code review system for Perforce and Subversion that even the git people could probably benefit from. Is it any surprise that one of its promised benefits comes from bridging centralized repositories, even of different types?

I made a very concerted attempt for 3 weeks to use git as a distributed wrapper around Subversion (using git-svn). I ended up with a repository that constantly broke — needing extremely arcane commands to fix it each time — changes that got lost, branching problems, days when users couldn’t pull new changes from my distribution repo, etc., etc. Git is just too complicated for what it’s supposed to do. When a user honestly expects you to run “git reset –soft HEAD^2” or some such just to return your working tree to sanity, he’s basically proven to you that it’s a worthless system.

Yes, it’s fast and efficient, and I’m sure that if I stayed within a very narrow band of expected usage it would have been reliable for me. But the truth is that I could never see asking my co-workers to switch to such an arcane and finicky system. SVK is vastly simpler in comparison (if all you need is a DVCS wrapper around Subversion, like me), with it’s 4 basic commands.

Compare that to the 20+ commands I kept having to use to fight with git — just to keep it usable, damn it! — and the answer becomes clear.

Hm, interesting. I personally use Mercurial for basically everything. I like it because it manages to be distributed and simple to use at the same time. Some people praise it because it’s written in Python, but for me it could be written in Malbolge as long as it gets the job done.

The reason why I avoid git is similar to the reason I avoid bzr. In the case of bzr I’m scared because it’s Canonical’s baby. If Canonical decides that their baby should have seven heads then it will have seven heads.

In the case of git, my concern is not with a corporate entity but rather with the fact that it’s heavily tied to the Linux kernel development team. I’m not sure how well supported it is on *BSD or Solaris, for example (and I do care about such things). It could be that it works really well on these platforms and that there are really active git maintainers in the communities. I don’t know, and right now I’m happy with mercurial so I have very little reason to investigate.

I don’t know if Linus’ comments about Subversion developers are fair, but I get annoyed by Subversion users, who assume Subversion is the One True revision control system. I don’t criticize anybody for using Subversion. Funny enough, I constantly find that I have to defend myself for *not* using Subversion. Reminds me a bit of a certain religion (no points for guessing which one), or Gnome users and developers.

You might be interested to know that we are now using and maintaining pdk at 64 Studio. We’ve set up a basic Trac site and will be doing some publicity work later so that more people get to know that this great tool isn’t dead. Cheers! Daniel

I have been browsing online greater than 3 hours today, yet I
by no means discovered any attention-grabbing
article like yours. It’s pretty worth enough for me.
Personally, if all website owners and bloggers made good content material as you probably did,
the internet shall be much more helpful than ever before.