It may be true that a bad workman blames his tools …
… but so does a good workman, if the tools are crap.
And git is crap. No, wait — it is much more than that. It’s not just poor, it’s malicious. When Sauron allegedly poured all his malice into the One Ring, he must have retained some wherewith to poison the sweet well of version control. Ever he seeks to spread discord and confusion — and what better way than by the notions of local and remote branches and various kinds of links between them? Or the distinction between the working area, the repository and the freakin’ index — a concept that we’ve all got along without quite satisfactorily, thank you.
Yet the world has flocked to git, no doubt due to the Torvalds imprimatur. Everyone assumes, heck, if Linus needs it to co-ordinate his totally unique world-dominating monolithic operating system, which has literally thousands of contributors, then, well, gosh, I suppose I ought to use it for my tiny six-source-file project that I and two close friends work on.
Which of course is exactly as sensible as saying that because the Air Force has legitimate uses for the Harrier Jump Jet, we should all be using them every time we want to pop down to the chemists for a pack of peanuts. But everyone wants to use it anyway, and — surprise! — the air is filled with the warming glow of constant mid-air explosions, and the earth polluted with the scorched remains of epic crash-and-burns.
We don’t need all that power and complexity.
Linus does, yes. And no doubt there are another handful of projects out there that really need all the git mechanism, too — GNOME, Mono, maybe the GIMP. But the other 5,999,999,997 projects? No. All we need is something more like … well, maybe not CVS exactly, but something closer to it in spirit. (Many times I’ve wished that when I made the jump from CVS, I’d gone to Subversion instead of git).
So git is much more powerful and complex than I, or you, need. And that would be just fine were it not that it doesn’t degrade gracefully. Those of us who need, say, 3% of its facilities can’t just quietly go about our business using those 3% and ignore the rest, because the other 97% keeps leaping out of dark corners and landing on our heads. Local vs. remote branches, conflicted merges, totally incomprehensible error message, commands that require whole paths to be specified irrespective of the working directory, commands whose names mean something totally different from what they mean in every other version control system, and of course version identifiers that look like 23bbcf847889c1fbfbb368b27e7b4ef3648879b1 rather than, say, 1.8. All that stuff is out there. All the time. And it’s scratching at the door to get in. And it often does.
The big lie
Like most people coming to git for the first time, I suspect, I started out with a conversation like this one, with someone who was genuinely trying to be helpful:
Me: I don’t know, it looks complicated
They: Oh, you can use it just like CVS.
Me: OK, so I’ve edited these files, I’ll just git commit the changes. Oh, that’s weird, it didn’t work.
They: No, you have to git add the changed files first, then git commit.
Me: Why? I already added them before, why do I need to add them again?
They: You just do, OK?
Me: Yes, but why?
They: All right, since you asked: [Long, complicated explanation that brings in half a dozen totally alien, and closely interrelated, concepts, about 7% of which sinks in. Then, when I am sure they’ve finished:]
Me: Great! Let’s go and have lunch!
No; you can’t use it just like CVS. I am increasingly of the opinion that much of my git pain is caused by having accepted this innocent lie. (That’s apart from the main wodge of pain that is caused by git’s fundamental evil, of course.) If you’re going to use git and not expend unreasonable amounts of energy in cursing at it, then you’re going to have to learn it from the ground up. Throw away the CVS concepts, learn the git concepts as though you’d never heard of version control before; think natively in those concepts rather than than thinking in CVS and translating.
And this I have, so far, signally failed to do. Despite having read half a dozen web tutorials. Sigh. I think this is going to require a real, printed book, just like learning Rails did. I feel another Long Overdue Serious Attempt At series coming on.
But, but, but. This is stupid, isn’t it? I don’t mind investing a serious chunk of time to learn something as profound and enlightening and world-changing as Lisp (or, evidently, to learn a made-up mythos). If conventional wisdom is correct, then when I have drunk deeply of the sacred wells of Lisp, I return to the overlands as a different programmer — not just one with more expertise, but one who can look at the world from a completely different direction. That is worth spending time on. That is worth some effort.
But git? Git’s just version control. I resent the idea of investing a month of evenings and weekends just to be able to check my freakin’ files in. Just to be able to do the exact same things I’ve been doing since 1990 with no difficulty until the last couple of years.
I don’t want to have to go through the Harrier pilot training course just so I can nip down the road to the Lidl in Cinderford without crashing into the ground or accidentally firing an air-to-ground missile at an innocent hospital. Not when I have so much stuff to do. (Remember, at the last count I am supposed to be learning Ruby, Rails and Scheme plus the Silmarillion, while also working through the exercises in Programming Pearls. Plus I have three dinosaur papers to write and a review to turn around and, oh yes, my actual job.)
I don’t need a Harrier. All I need is a VW Beetle. Or indeed a bicycle.
So I think that for my own projects, I’ll be going back to CVS, or maybe Subversion. For other projects, unfortunately, I will need to keep using git, because my colleagues are on it. (Although I know several of them would ditch it just as happily as me.)
Oh well. Progress, eh?
Update (later the same evening)
Many thanks to you all for your comments. It’s interesting how many of you recommended Mercurial over git, and that in most cases it was not because of the quality of the tool but the existence of a really good tutorial. (Good git tutorials may exist, but I’ve yet to find one that works for me, after several false starts.) I hate to think I might have to learn Mercurial first and then go on to git, but maybe that’ll be what it takes before I truly grok it.
(But I should have mentioned one thing about git that I do love: git bisect. Highly recommended. I went through its procedure once by hand before discovering it, and it was like a ray of light.)
And to the few of you who thought my problem with git is the need to type “-a” when using the commit command … No.