Git is a Harrier Jump Jet. And not in a good way


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.

99 responses to “Git is a Harrier Jump Jet. And not in a good way

  1. Try mercurial. It’s the same thing, but I like it better.

    Plus, Spolski has written a kick-ass tutorial for it at

  2. I have no opinion on whether or not git is suitable for you, but you’ve missed is the amazing work over at github.

    For my corner of the programming universe, github has completely outpaced Google Code and Sourceforge as the go-to place to publish code. It’s so efficient that you actually like to push code to github rather as opposed to all the high-ceremony project creation junk on SF.

    Some of the features of git make me love it, particularly first-class branching (as anyone who’s had to handle branching in cvs or svn knows, it’s brutally painful compared to the effortlessness that is branching in git) and disconnected (and fast) commits.

  3. +1

    I’m ignoring git, until “-a” is the default for git commit (etc)

  4. While people are posting their favourite tools, consider also “fossil” ( It’s distributed like git, _much_ less obtuse, and brings some other useful features to the table (integrated ticket system? Check.)

  5. You’re right about git. I use it extensively and it is a powerful tool with advanced features.

    I second what “mos” wrote– try mercurial. It’s a great tool that is easier to learn, in my opinion, and still gives you excellent distributed capabilties.

    For Mercurial hosting, try

  6. The best analogy i can think of for git seems to be the Hole Hawg that Neal Stephenson describes in his essay In the Beginning was the Command Line. It is quite literally the drill that when the bit catches flipps you end over end and causes you to kick the lader out from below leaving you hanging from the side of a building… but it drills holes very well.

  7. Branden Rolston

    “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?”

    I don’t think the why here is a long technical explanation, that’s the how. The why is that you might want to commit your changes set of files as separate logical commits. Maybe you notice and fix a small unrelated bug while working on a feature. With a CVS-style VCS you might commit them both and mention them in the message (messy). Or revert the corrected file, commit the feature, restore the correction from a patch, and then commit it (annoying). With git you can simply add and commit them separately.

    You’re right – Git is nothing like CVS, and is a strange beast if you don’t learn it on its terms. (Whoever says otherwise is making a well-intentioned but misguided attempt to help you swallow the DVCS pill.) But it’s full of little freedoms which will seem like edge cases until you find a useful place for them in your workflow. If you dismiss it wholesale you’ll miss out on some really neat things.

    Git didn’t click for me until I read “Git from the bottom up” ( The Git Parable is another good one – it explains it as a series of scratches for particular itches (

  8. Pingback: » Blog Archive » Finally, someone who doesn’t love git

  9. I think that you’re generally right (though exaggerating), but a few tricks will make your life somewhat easier:

    * Git will recognize any unique prefix of a commit, so in your example, you could almost certainly write:

    git diff 23bbc HEAD ## My wrists! They’re cured!

    You in fact do *not* have to use git add for changed files, the command you’re looking for is:

    git commit -a ## commit everything that’s changed

    Also, if you don’t make a distinction between local vs. remote branches, it means the server has to track *every branch*, that anyone ever makes, *ever*. The ability to have local branches (and favoring them in the syntax vs. remote branches) encourages people to do the right thing – work locally in a branch, then merge (or better yet, rebase) to master.

  10. There is already a real book. You can get it in print or online.

  11. I came down here to post was mos did. I’ve used SVN for a long time, and the migration to Hg with the hginit tutorial was really painless. Within about an hour I was up and running…

  12. Not that you’re looking for yet another VCS to learn, but darcs ( is one that I’ve had a lot of fun working with for tiny one-man projects. I find it a lot easier to wrap my head around than git and the command line interface is very user friendly.

    There’s also a free darcs hosting service now ( so it’s a breeze to use it as an svn-replacement (i.e. Having a central server where you push your work to)

  13. They weren’t quite truthful when they said you can use git just like CVS.

    But what are you doing, at a level of a nip to the store, that requires more than a day of reading tutorials?

  14. Finally, someone admits it aloud :)

    Git is really confusing. Out of curiosity I went through official tutorial last week, and I should admit it made things only worse. I really doubt I will be able to reproduce any of their sample workflows without looking at the manual.

    Luckily for the rest of us, git isn’t the only VCS out here. My favourite now (partly because that’s what we use at work) is bazaar. That one is way closer to old good CVS/SVN way of doing thing. Mercurial is another good and simple candidate, though it is slightly less obvious to my taste.

    I recall being somewhat upset by it’s requirement to use explicit push when you work with remote branches (whereas in bzr you can bind your local branch & use it as if it was CVS-style check-out). Another thing which really confused me is the limitation of being able to roll back repository state by 1 step only. As I tried to roll back incorrect merge&commit my repo was stuck in quite crazy state.

  15. First of all, no one immediately understands all the points of a complicated tool (as all VCSes are) the first time around. Many tools don’t begin to make sense until after several tries; I know VIM and it’s modes threw me for a loop for quite awhile.

    Git is more complicated than CVS or SVN, yes, but it’s a different kind of complicated. Try to keep several developers working on local, ever-changing branches of the same codebase using one of them and you’ll quickly descend into madness. Set them up on Git or Mercurial and, once they grasp the concepts of commit, push, and pull, they’ll have little to no problems (most problems at that point will come from merges).

    It sounds like you’re using Git in a solo environment. That’s the best way to start. But maybe you’re thinking of it in the way you worked with CVS. It doesn’t work that way.

    You mentioned `git add` for changes. Really, I think this should be renamed. It should be `git watch` or `git follow` for adding a file into Git the first time. “Tell Git to watch this file for future changes.” And then it makes sense to do `git add` when you make a change because you’re adding the changes to those files. This two-step process, by the way, is a real boost. You can review your commit before you make it, only commit some of the changes with a certain method, or commit changes to a different/new branch. I’m fairly certain you can’t do either of those in SVN.

    Anyway, I’d encourage you to give it another shot or, like mos suggested, try Mercurial. If you need any help, feel free to hit me up.

  16. A second ack on hg and Seriously go check it out.

  17. I used (and administered) subversion for six or seven years but I’m now a huge fan of git. At first I couldn’t see the benefit, but I’ve been using it for about a year now and now find svn incredibly limiting.

    It’s no exaggeration to say that git has changed the way I code – it’s made it more fun.

    Also, you don’t have to add first then commit. You can just use git commit -a, which does the add for you then commits!!

    Mercurial is good too. I actually learned that first (it was easier to grasp) and ended up switching to git later. Mercurial taught me the benefit of DVCS so when I had another glance at git it all made sense, and I liked it more.

  18. I went from svn to git and I use it as svn, I know only 3% of git and works for me

    svn checkout -> git clone
    svn up -> git pull
    svn commit -> git commit -a (and maybe you want git push origin master)

    that is all I know about git (maybe a little more but not so much more) and I manage small 6 file projects and big projects with it.

    if you want to complain you will find a reason, just do git commit -a instead of adding the files again.

  19. >They: Oh, you can use it just like CVS

    See *there’s* your problem. Git is not like CVS. At least read the “re-education” part of, then try git again.

  20. I’m not sure whether this is flamebait or what…

    From your post I find one thing that you think is bad in Git. One.

    So because you have to ‘git add’ files, it makes Git the most evil vcs? Umm, okay…

    I guess you never heard about the -a switch for ‘git commit’ which removes the necessity of using add. ;)

  21. Most of the tutorials out there are crap. The PeepCode video is rubbish.

    I tried use it for about 6 months, and pretty much gave up.

    But the “Pro Git” book by the GitHub guys made me finally get it.

    Their diagrams really rock for explaining, though you may need to read the branching and remotes chapters a couple of times.

    Once you get used to insanely cheap branches and trivial merging, it’s hard to go back.

    I won’t deny the learning curve is steep though.

    You really have to buy into changing your workflow for the way a distributed VC is meant to work instead of trying to use it like SVN though, or you’ll just end up wanting to break things.

  22. Some of the differences here seem to be about the differences between a distributed version control system and a centralised version control system. I wrote an intro to DVCS concepts if you’re interested:

    The 1.8 version is specific to CVS; subversion uses a (repository wide) number rather than a per-file number as with CVS. However, most DVCS will use an SHA-1 hash, like the string you noted. (Just FYI, you can abbreviate that to a unique prefix: so you could refer to it as 23bbc)

    I also dont like git’s index generally – but if you don’t like it, don’t use it. You can use git commit -a and you only need to use add on new files. If you want to do this a lot, then git config -global commit -a will allow you to use git ci in the future.

    It’s true that git is different than CVS; but any DVCS is different to any CVCS. That doesn’t make it bad; just different. On the other hand, it’s nor just Linux users: Eclipse is moving over to git and Apache has had readable git repositories for some time. And even if Hg is your favourite DVCS, that is still different in the same way.

    Lastly, if you really want to stay with SVN then you might be interested to know that GitHub, a popular Git repository hosting service, now has (experimental) writable support for SVN clients.

    If you are looking for a book recommendation, then ProGit is available to read on-line for free.

  23. There seems to be a few conflicts (lol) here:

    – Part of it is DVCS. If you’re coming from SVN or CVS, the transition is very hard (I’m lucky, in my early 20’s and just started developing for serious about a year ago, so unlearning was easy). I suggest you read the first chapter of Spolski’s HG init, linked above, if only for the catharsis of reading his pain in the transition.

    – Part of it is the git approach: it’s not a single program, rather a series of many components that are stitched together by dozens of little scripts. It’s like the archaic commands and interface of vim with the Operating-System-Not-Editor quality of Emacs. But like those editors, it’s well-suited for a number of people, and incredibly powerful after you conquer the learning curve.

    For both parts, I echo mos, and suggest you try Mercurial. It’s a single program, has a much cleaner interface, and has much better materials for learning. These include Spolski’s tutorial, or Bryan O’Sullivan’s book. I promise it will take you less time to figure out then git, allowing you to taste the love of DVCS (because since I’ve picked it up, I’ve never want to go back).

    (alternatively, if you want to rough it out with Git, there’s the community book and Pro Git, both free).

    Good luck!

  24. Seriously? 1086 words on why you won’t use git? Seriously?

    I believe it took me less time to learn git than it took for you to write this article. It’s really not that hard or complex.

  25. I used Subversion for everything once. The two things that sucked for me were its inability to go offline (I write a lot of code in my commute) and its inability to merge (I usually have multiple feature branches on the go at once).

    I resisted git for a while and tried svk instead which was very much closer to what I need but still wasn’t strong enough when it came to managing multiple feature branches.

    So three years ago I finally put aside a weekend and converted everything to git. I knew that I’d need to do some unlearning so I really tried hard to forget what I thought I knew about version control.

    Now I use it all day for just about everything, even the most trivial of things. If I make a change to a file and think I might want to keep whatever I changed, I just do a commit. No repository already? git init, done.

    Same for those six-file projects. I like to commit. I do it a lot. With git I don’t need to think, don’t need to wait, I just save, commit, save, commit. Hell, a number of times I’ve considered adding “git add ; git commit” to my editor’s save function. Haven’t quite got there yet though :P

    I’m not trying to convince you that you’re wrong, just talking a little about my experience. I think you’re right in that git is harder if you try to use your CVS/Subversion skills and apply them as-is. I had some sense of this from the outset though and didn’t assume any of it would carry over.

    Subversion is still a fine version control system. If it was for me needing the ability to commit while offline I may never had changed at all. I can’t imagine life without git now, but honestly, if it does nothing for you then stick with what you know. Its the same reason I still use vim, mutt, etc. Way back when I learned them they were the most appropriate for what I needed, and nothing since has provided a feature so compelling that its worth my time to relearn. Tools are boring and I’ve got better things to do!

  26. Melvin Ram wrote:

    I believe it took me less time to learn git than it took for you to write this article. It’s really not that hard or complex.


  27. So don’t use Git. Who cares if it doesn’t work for you and how you like to work?

  28. Jeff Roberts

    If you just want to use it to do what you were doing in 1990, why are you using git? See Linus’s talk about git here -> Tech Talk: Linus Torvalds on git, and maybe it’ll help you figure out what you’re doing wrong *nudge-nudge*. Mercurial is usually the suggested alternative to git but they seem too similar to me to understand why you’d pick hg over git. The real alternative to hg/git, IMHO, is bazaar. I’d guess bazaar wouldn’t have any problems taking you back to your workflow from the ’90. Point, click, commit.

    My company is still using svn and I’d like to move new projects to something decentralized. Git would be my choice but bazaar seems more friendly for my coworkers.

    Playing with your analogy… Linux is the Harrier Jump Jet, git is just another instrument inside it. If you’ve flown enough hours w/ Linux you won’t have much difficulty picking up a new instrument. Otherwise, trying to learn the instrument alone will involve also figuring out the psychology of the world it was created for. That could take far more than a month. I feel it was a worthwhile investment for me but it sounds like you have other interests using that time. To each his own.

  29. Have you read Git from the bottom up? Mental-model adjustment, yes. Worth it though, also yes (IMHO).

  30. Pingback: Age: absolutely minimal version control « Software Tools

  31. Here’s a version-control system in two rc (Plan 9 shell) scripts. It’s got about none of git’s features, and is woefully inefficient, but it does one thing really well: have a backup when you make a bad change, if you use it regularly.

    (Mike, feel free to delete my two previous comments on this post.)

  32. “Git’s just version control.”

    That’s the big lie; Git is change control, which does require more user interaction to tell it what exactly constitutes a “change”. If you’re the only developer and want version control, use Subversion. If you’re doing Real Work in a Real Dev Shop, you should learn Git.

  33. That there is some learning to do to use git — agreed. That it takes a bit of a mind-set change (compared with cvs/svn) to become proficient with it — agreed… But I don’t agree that only huge projects benefit from git. I use it daily, even for my personal projects for which I would never bother to set-up a cvs/svn repo.

    How about asking yourself the following questions:
    (-) how often would you like to update/browse/… your repo while not having internet access? (I don’t know about you, but to me it happens quite a lot).
    (-) How often do you use branches with cvs/svn? Do you think you’d do it more often if creating/manipulating/switching/merging/… them would require just a few keystrokes?

    As for learning git: I think a graphical helper tool (such as qgit) can be of great help, especially at the beginning of one’s journey with git.

  34. I can’t really comment on your learning experience. I frequently meet people who don’t get along with git, so I know it’s an issue.

    But I disagree with “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.”.

    Version control is not “just” version control, it’s a first class tool for every programmer, up there with recursion and all that jazz. A programmers work is transforming code from one state to another. Git treats these transformations as first class objects, allowing you to rewrite or reorder them, have alternative transformation branches, send them around etc.
    None of this is impossible in cvs, but it’s just so super painful.

  35. > Not that you’re looking for yet another VCS to learn, but darcs ( is one that I’ve had a lot of fun working with for tiny one-man projects.

    Does darcs still fall down when working on larger projects? I loved darcs and used it for a few months but any time I started getting more than a few thousand lines of code, bad performance started happening. I get most of what I liked out of darcs with git rebase and git add -p.

  36. I’m using git on a very small project that I’m working on in my spare time (so far, there’s nothing worth reporting on it). To learn git, I used and read the Git – SVN Crash Course. Hopefully you can find something similarly useful using instead.

  37. I felt like that at first but stuck with it because I used a few projects. After working with it for a little while, using SVN is actively painful – slow, basic features like merging or reverts are primitive and error prone where fit simply just works quickly and easily.

    The guides mentioned are definitely good but the biggest step is using git the way it’s intended: lots of branching, partial commits and rebase / merge to keep your downstream changes clean, etc. Using it like CVS makes it feel like what you describe but it’s like complaint about a hammer working poorly with screws.

    (as an aside, I very rarely use hash ids – branch/tag names and relative references are all you need for almost any case where you aren’t trying to be too clever)

    Mercurial is worth a look but I’ve found it a lot harder to use than git for advanced tasks – patch queues just feel awkward compared to git rebase.

  38. If subversion had the advanced merging of git or other DVCS it would be totally fine. But that was the decision maker for me. I have never had a merge conflict when using git.

    I also agree that github is a really nice perk that comes with drinking the git kool-aid.

  39. So this entire article is based on that one extra step?

    Boo hoo.

  40. It’s funny, but having used Mercurial after having used Git… I find Mercurial annoying and restrictive.

    You complained about the staging area: that’s one thing I absolutely love. I also love that the commit hashes aren’t hidden behind a revision number. I actually find it easier to reason about what Git is doing.

    You’re probably right in that it’s harder to learn than some other VCSes, especially if you’re trying to hammer it into a CVS-shaped hole.

    Maybe this will be of some use:

  41. I recognize the usefulness of a DVCS, but I also agree that it is not a quick jump from CVS to git. You *will* have to spend some time learning it. In fact, I’m with you in that I haven’t yet devoted the time required to understand how to use it well. I can use git well enough to clone repositories and update them from the source repository, but I haven’t switched to using git for my own work.

    In fact, I decided to learn to use hg *because* of Linus’ presentation to Google about git and DVCS. He convinced me of the usefulness of DVCS, but he also turned me off of git with his… presentation “style”. A style that is unfortunately shared by many git proponents out there.

    However, I recognize that git is undoubtably powerful, and I should learn it well enough that I can use it to collaborate with people who choose it for their work.

    Good luck fitting in the time to learn about git.

  42. Simon Russell

    I’d have to say that I pretty much thought the same way as you initially, but after using it in a team and then reading Pro Git (definitely recommended), I’m a convert.

    It’s actually so useful that it changes your workflow a fair bit (in a good way).

  43. David Turnbull

    I can’t really see why people can’t put effort into their tools if they’re going to blame them.

    You program complicated software with complicated frameworks and you don’t want to put effort into your scm… why?

  44. I’ve found a tutorial called “Understanding Git Conceptually” ( to be very helpful. It’s not as punctilious as the official documentation but it doesn’t gloss over important details either. It explains how git works, what some common use patterns are, and why.

  45. I am about to adopt Bazaar. Time and again I hear some negative things about it though. See here:

    Does anyone here has had any unexpected issues with it?

  46. Bzr is quite handy. I use it daily at work (with a source tree of some 300 megs, and 500 megs of compressed history).

    What I like quite a bit is its treatment of versions & the notion of master branch.

    On the downsides — some stuff is quite slow in it. Doing “bzr st” in the very morning on cold disks can take quite a while, and bigger merges / pulls can take 20-40 seconds (or more if you are unlucky).

    Some of the versions we used (especially on windows) had problems if hard-interrupted by ^C. Leaving nasty locks in the repository.

    For the rest — stuff went quite smooth. Branching/merging is quite good. The whole system is very easy to understand & maintain.

  47. “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?”

    I quite understand this, and while I think that the index is very interesting and powerful, I’m not convinced that it’s a Good Idea for reasons pointed out Eric Sink in “Git is the C of Version Control Tools” ( “And this is where Git’s index is both cool and not cool. One of the best practices I suggest in Source Control HOWTO is to never use a version control feature which encourages you to checkin code which you have never been allowed to compile and test. This is exactly what Git’s index allows the developer to do.”

    That said, it’s really not much different from when I use Perforce at work (which I like), where I have to remember to “p4 edit” a file before I can make changes to it (they’re checked out read-only by default).

    Annoying, but not so annoying that I gave up on it. The features of GitHub really make me want a private label version that I can install in my own datacenter.

  48. My God, do you want some cheese with that whine?

    Seriously though, I’ve heard similar complaints and confusions before. Not just about git but from vim. Not just about vim but about .

    “Why the *hell* would you want a modal editor to *EDIT TEXT*!!!!!!!! IT’S TEXT!”

    6 months later: “OMG I LOVE vim! I totally get it now!”

    “Why the *hell* would I want to add the file *AGAIN*! I ALREADY ADDED IT!”

    6 months later: “OMG I LOVE git! I totally get it now!”

    I’ve heard it time and time again.

    I have no desire to argue about the quality of tutorials because I’ve read them and I ponied up and worked through them. If you don’t understand the index and the object model then you don’t get git. You just don’t.

    [I absolutely love the index and I fell in love with `git add -i` when I discovered it. I die a little when I have to touch CVS or SVN now.]

  49. Betrand Russell

    > And git is crap.

    Please do not call something crap because you do not understand it, are upset that it is being adopted, or that it is too powerful for you, or whatever the hell else you were trying to say with this techno wankery.

    Yes, it is hard for some to learn if they’ve never used a DVCS.

    > So git is much more powerful and complex than I, or you, need.

    > All we need is something more like … well, maybe not CVS exactly, some something closer to it in spirit.

    Just because you have a blog doesn’t mean you speak for any of us. Use the word I, not We.

    Git is oustanding for working with opensource software. Topic branches, easily forked code, having the full version control system available locally, rebasing. The fact that you think 99% of projects can’t use things things just says you don’t understand how or why to use them. Not that we all don’t need them.

  50. Anonymous Pedant

    Well, that’s a misspelling I’ve never seen before. Being Latin rather than French it’s “imprimatur”, not what you wrote.

    [Mike says: thanks, AP, I’ve fixed this now.]

  51. Thank you, git has been annoying me all day. Mercurial is so much simpler and the commands make so much more sense (and there’s less of them to get in the way). I still haven’t figured out if it’s even possible to do something like “hg in” or “hg out” with git.

  52. @Branden Rolston:
    You do know that you can commit just some files in SVN also, don’t you? No need to revert things.

    Apart from that, I’ll add another vote for mercurial. For some of us, it just fits better than git.

  53. Couldn’t agree more. It’s funny that just yesterday evening I made the decision myself to quit trying git for my projects and go back to using good ol’ svn.
    I actually did get a book on git, and even spent a while watching of video of Linus explaining (poorly I might add) what’s so good about git. But in the end of the day, even though subversion has its share of problems, I just couldn’t figure out why I should spend so much time trying to figure out how to work with this unwieldy version control system when I can spend it being productive or learning an actual programming language (Scala in my case, already been there and done that with Ruby).

  54. It’s a lie. A car is not like a bike. With the latter I just get on and go. With a car, I need to open and close doors, use something called the index^Wignition, need to maintain fuel and insurance, and take time to learn to drive, and all that added complexity simply isn’t worth the effort for 99,9997% of the people.

    So it is with git. It’s actually version control, and not just a glorified backup.


  55. Hugh Sasse

    I don’t think it’s a Harrier (which I gather are being phased out, BTW). I think it is a Model T Ford. These things have not been around for long, git is a significant development over the existing ones in various ways, but the pedals are not where you will come to expect them to be, you still need to know about what the engine is doing, there’s that annoying starting handle instead of just a key switch. But these things take time. People still had to know what to do with the choke when starting a car well into the 1970’s. But this Model T Ford is allowing lots of people to get out and do things they couldn’t before. Things will improve.

    I found the Pragmatic Version Control Using Git a good book to get me on the road, but it could be improved for use as a reference later. There’s still lots I don’t understand.

    I recently had git under (the old) Cygwin (which I hadn’t upgraded because [who cares why?]) drop everything on the floor during a merge, but upgrading Cygwin and then git allowed the merge to work once I’d pulled the repo out of a backup. So it isn’t perfect, but what is? [Yes, I was furious when that happened, but I don’t know what the difficulty was. Given it does so much the implementation will be a lot more difficult to get right than, say, binary search. But it has that: git bisect. :-)]

  56. Odd.

    After using SVN for years and never daring to do anything even mildly non-trivial with it, particularly without a graphical interface, I found git quite refreshing in comparison. Heck, I have created branches and merged them back in!

    I also found the man pages and command line output very good _for open source standards_. That qualifier may mean that they’re still far from perfect, but they remain significantly better than loads of other software, including SVN.

    With the progit tutorial site, I also found that can figure out most of the things I need to do.

  57. Hugh Sasse, very interesting alternative analogy with the Model T, thanks for that. I will ponder this.

    You comment has also left me wondering whether git bisect properly implements binary search, or whether it fails on any of the edge cases :-)

  58. s/upgrading CVS/uprading Cygwin/;
    Don’t know how I made that mistake.

    [Mike: I’ve fixed your earlier comment. It does make more sense now :-)]

  59. This blog post came as a shock to me :) for two reasons: a) because I agree with most of what you wrote prior to this b) because I really like Git.

    I came to realize that maybe you are right, as I only use a small part of the Git functionality – I haven’t really used it in a large, multiple-committer project and I haven’t yet setup a remote repository. So maybe Git is not as good in a moderately-sized project.

    CVS and Subversion are very idiosyncratic and high-maintenance – I was using both in my previous job in relatively medium-sized projects (3-4 devs). Both tended to get in the way by way of strange errors, incomprehensible branching behaviour and corruptions. (I remember once, the project team said a little prayer before a merge…). Subversion especially tended to behave erratically if you did something wrong (e.g. delete a file, without consulting it first). If you used it on a complex Java project, you could have one thousand little .svn folders scattered everywhere.

    Git is very simple and fast in comparison. I tend to use no more than four or five commands to do everything I need and get no strange hiccupps in the process. I haven’t used it with many commiters or a remote repository but I far as I have seen, it doesn’t add much to the complexity of its use. Need to try merging to be sure.

  60. Kristof Jozsa

    love it or hate it but git is all about the index. if you dont need it or dont want it, go with hg (mercurial), it just works. but for christ sake, dont degrade your highly skilled technical writings with a post like these mentioning CVS in 2010.. please..

  61. It seems two topics are getting mixed here:
    1. DVCS (Git, Mercurial, Bzr) vs. central (Subversion, CVS)
    2. Git vs. other DVCS (Mercurial, Bzr, etc.)

  62. I’ve seen a trend with people who don’t “get” git, most of them seemed to have used version control as a glorified backup. When it should be a collaboration tool, including collaborating with yourself via test branches.

    This is is a great rant against git, I guess, but unless I missed it there was absolutely no mention of your actual work-flow. As someone else said you could be trying to use the git “hammer” as a screwdriver and that’s why there’s such a disconnect.

    As for my work-flow: I was using git just yesterday to edit a single file script (it ended up as three files). Any time I had any new functionality to add I would create a topic branch, add the functionality, test it, and then merge it back into the master branch. If I was stuck with say SVN I probably wouldn’t have committed half as much, and I would have been far more concerned with testing new ideas…even on something so small.

    Sure, I was the only one working on this but even when I was collaborating with multiple other people I hardly changed this work-flow at all. Compared to the last time I used SVN professionally, where there was only a single branch in the year I was there and surprise surprise the merge back into the main branch was a pain in the ass.

    I guess I’m just wondering if you have to actually spend so much time and effort to learn git, were you really using version control to it’s fullest to begin with?

  63. having a Harrier Jump Jet to launch rockets against these disturbing birds on the way totally rocks.

  64. brad dunbar

    Yes, git is complicated. No, its not like svn. However, I have gotten a lot of mileage from the small amount of knowledge I’ve grokked so far.

    Also, I don’t buy your “source control isn’t important enough to spend time on because its just checking stuff in” argument. If checking stuff in was all I did with my vcs, then svn would work until the end of time. However, projects with just a couple of people (less than ten) can have big problems merging when using svn. At least that’s my experience.

    Lastly, (I know this is a long post) github really does add one tremendous feature. That feature is the ability to fork someone’s code without asking them, fix a bug, and then have the patch show up in their queue seamlessly. It makes the bookkeeping and barrier to entry much lower.

    Keep us updated on your progress with Hg.

  65. I’m confused why you need to use “git add” after you made edits to a file you mentioned had been added in the past.

    I haven’t run into a situation where a “git commit -m ‘this is my commit message’ path/to/” doesn’t suffice after making edits to files already in the repo.

    Can you greater explain the situation as to why you are needing add?

    In addition, I don’t agree that the -a flag is what you need based on your short dialog above unless you want to commit all of the changed files. However, this will still ignore any files popped out due to a required manual merge, so I have stopped using -a completely w/o any problems.

  66. > Me: Why? I already added them before, why do I need to add them again?

    … Huh? Git is apparently WAY over your head. You aren’t adding the _files_, you’re adding the changes to the index, which is what gets committed…

    You know what? Nevermind, just go back to 2001, err, SVN and your maintenance programming for a big corporation’s java project.

  67. Pingback: Top Posts —

  68. The trick with git is to realise that the fundamental unit is not the file, it’s the changeset.

    Files don’t really exist per se in a git repository. When you ask for a file, that file is reconstructed by replaying a bunch of changes. That’s why you have to add all the time: add doesn’t mean add this file to the repository, add means add the changes I made to this file to the next commit.

    This is significant, because it allows you to separate your work. If you’re doing some weird experimental hacking on the mass-spring physics engine, and in so doing you find a bug in the logging system then you can, right there, without breaking stride, make a commit containing only the fix to the logging system and be sure that commit will make its way back to the main project trunk, even if you abandon your mass-spring physics hackery.

    Like with Ruby and closures, whenever I have to go back to SVN I wonder how I ever managed to get anything done without all this magical branchyness.

  69. One of the things I like about Darcs is that it doesn’t try to reuse terminology for something different; you won’t *expect* “darcs record” to behave exactly like “svn commit”. While people will *still* try to pretend that it’s just like Subversion/CVS, it takes more mental effort to get it wrong…
    (And/but, well, for 1-person projects, I *can* use it like Subversion, by never synchronising with a remote repository — which saves me the work of setting up the remote repository, and makes it more convenient to switch between my all too many computers…)

  70. @Damian: While handling changesets in all directions is indeed the hallmark of good version control, git does *not* store changesets at all; it *does* store each version of the file tree (unlike svn which does store diffs). Changesets are only ever computed; even the packed repository format does not work on changes between commits, but only by compressing similar contents, which may, but may not, be successive revisions of a file.

  71. You have a habit of convincing me to change my mind with your articles. This was far from that. :)

    “Like with Ruby and closures, whenever I have to go back to SVN I wonder how I ever managed to get anything done without all this magical branchyness.”

    This is essentially what I wanted to say. Yes, you have been developing using a centralized VCS for years and been just fine, but many people write solely C/C++/Java and feel just dandy, too. It’s a change in mindset, and a change in how you work.

    For the record, I was introduced to version control with hg, got forced into git and became addicted, and *then* encountered svn. Oh god, I hate it so much.

  72. Oh, and yes, the UI for git is terrible, as is to be expected of anything created for Linux kernel development. You’ll notice that git is particularly popular among the Ruby crowd, who use git *despite* its cryptic commands and error messages, which is a bit surprising, since that community has such a high focus on common language and prettiness and such.

    I cannot speak for others, but I use it because the benefits outweigh all of the things that you mentioned (and a few more :) ).

    Ah, but I was attempting to avoid trying to persuade you, as that seems to be useless at this point in time. Just know that we have our reasons for using this crazy tool.

  73. One of my professors (probably ripping someone else off) told me “A good engineer is someone who is too lazy to want to do any work, but curious and creative enough to figure out a way to make any work they have to do easier.” I think that about sums up a lot of CS for me… On that tip maybe this will help with git:

  74. I second the motion that since having to add a file again is the gripe you spelled out, then explaining why commit -a doesn’t work for you– what kind of situation or goal of yours requires you not to do that– er, you should spell it out.

    I have maybe half a clue about git, so I don’t know. It would probably be instructive. An expanded version of that is: why don’t you teach the rest of us both the concepts and use of git, in as angry (but fair) a way as you like, as a way of both coming to terms with git and explaining to the rest of us what you’re getting at?

    I suspect what you’ve done is try to turn an environment into something it just isn’t, something it took me a long time to decide can’t be other than a hell. What larned me was customizing the locations of Apple-supplied files in Mac OS to much saner places, then upgrading Mac OS. Oops, the upgrade produces a confusing mess and 3/4 of my settings are lost. I finally admitted that customization doesn’t overcome or win a conceptual disagreement with someone much larger than you.

    I worked for a long time maintaining a changeset-based, but not really distributed, version control system. There are at least two mini paradigm shifts between SVN (omg forget cvs) and git. I would say three:

    changes vs. versions as the real things (it is confusing that in git it isn’t clear whether this is the case).

    distributed, so handling issues of working separately, then resyncing.

    decentralized, so there is no authority to allow, e.g., a sensible name for something. git is decentralized even though typically there’s one repo everyone most wants to show up in.

    None of this addresses whether a system makes conceptual sense or is sane to use. Me stop now.

  75. Pingback: Still hatin’ on git: now with added Actual Reasons! « The Reinvigorated Programmer

  76. > I loved darcs and used it for a few months but any time I started getting more than a few thousand lines of code, bad performance started happening. I get most of what I liked out of darcs with git rebase and git add -p.

    Which version were you using ? The current release is 2.4 and has improved over the previous one in terms of performance.

  77. I’ve looked a git quite a bit. I’d even go so far to say that I understand it… but it’s interface sucks! Many people who like git will tell you that the interface is just chrome and there will be a million better ones, but there are very few even now that git has become popular.

    That is why I keep going back to mercurial. Mercurial has commands that make sense and are easy to use. Besides, many of the git features are available to mercurial as plugins now. For example, the ability to ‘stash’ files before you checkin.

  78. Monotone ( has the bisect command that you like with git. Linus liked monotone, but said performance was not what he wanted and instead of helping to fix performance, he created his own. Oh well. So is open source.

  79. I spent some time comparing and contrasting git and hg about a year+ ago.

    What I found was that git was not user-friendly or Windows-friendly. That’s been marginally improved since, but it’s still not up to hg’s standards.

    A best use of git requires a study of git internals ; however, hg does not require that for best-use.
    hg’s plugin system works seamlessly on Windows and OSX.

    The more obfuscate-y functionalities of git are available in hg, either as a built-in plugin (disabled by default), or as an external plugin.

    hg has bisect built-in, by the way.

    I would isolate the lack of customer focus with git as the central issue in git development. This has induced an inability to work seamlessly in Windows, unneeded exposure of the user to the guts and cryptic commands.

    hg Just Works(regardless of operating system). And that’s why I use it.

  80. Pingback: You could have invented git (and maybe you already have!) « The Reinvigorated Programmer

  81. Your whiny over-exaggeration does little to further your argument . Perhaps we can find some blocks for you to play with.

    I use git on a windoze machine for a Ruby on Rails project and I couldn’t be happier with git. Here’s my normal workflow:

    git status

    git commit -a -m “what was done”

    git push repo

    What is so difficult about that?

  82. I use git for github. That’s really the only reason.

    If there there were a darcshub, I’d be very tempted to use that instead.

  83. @Paul I have no problems with git on Windows… What are you doing that is giving you problems?

  84. MuppetGate

    Thanks for using the term ‘windoze’ early in your post; a good indication that I won’t miss anything by ignoring the rest of it.

    I’m a big fan of SVN but I know that merging branches with it can be a nightmare. I’m going to take a good look at Git though, because it sounds like Mike is trying to use it like he used CVS.

    Dunno, perhaps a better analogy would be ‘climbing onto the canopy of a Harrier Jump Jet and trying to ride it like a skateboard.’

  85. @SeanJA Git on Windows is fat (120M) and slow.

  86. @Bouiaw I feel sorry for you that your computer cannot handle that (it is running within Cygwin to be fair…), mine however can and I have no problems with it.

  87. Pingback: Thinking In Rails » Blog Archive » Links of the Week [05/16/2010]

  88. It may be true that a bad workman blames his tools..indeed it is true :)

  89. Pingback: The long-overdue serious attempt at The Silmarillion, part 3: that was awesome! « The Reinvigorated Programmer

  90. Boy… too many comments for me to see if someone already addressed this, but here’s something that (a) only git can do, and (b) even small projects need if they’re long-lived enough and there is team turnover — which is true more often than you might imagine, especially in the corporate environment.

    Git tracks not files but *content*. Say you have a function in a file that has lots of history, and that is handled like egg shells by the dev team because it is critical and complex. As a result, anyone tasked with making a change to it will spend some time looking at the past history of the function, to understand the various changes that happened to it and why.

    And say one day *recently*, this whole function moved to a different file as part of a refactor.

    *Every* other VCS in the world will effectively lose all the old history. Even with those that don’t lose it, you’d have to *know* that this function was in that file earlier in order to look at its past history.

    Git? “git gui blame newfile.c” will tell you, when you mouse over those lines “oh hey it looks like you’re interested in this function. Well that’s all very well, but it originally came from that file and was moved or copied here in that commit… want to go over there and see its history in that file?”

    OK that sounds like Clippy ;-) It’s not as chatty as that, but you get the idea :)

  91. I admire all the people who’re responding to you. I now re-read this post, *after* I had added a sane, polite, response, describing a feature I consider really important *and* unique to git, and I now believe I wasted my time.

    You, sir, are a very expert, very thorough, very painstaking, troll with lots of time on your hands… The fact that you seem to be a JRRT fan is not sufficient to redeem you, I’m afraid.

  92. What makes you think you wasted your time?

    Lots of time on my hands? *cough* *splutter*. How very, very wrong you are.

  93. Hey, thanks!

    I wasn’t aware of the git bisect command… I tried it and…. waster half an hour trying to figure out how to revert to my previous stashed files… :-)

    Now I know…

    Git is a lot of “learn by f**k ups”…

  94. You have all my sympathy!
    I had exactly the same feelings/problems about GIT!

  95. Pingback: fl0blog » Blog Archive » Learning git

  96. You had me until you said VW Beetle.

    I can see where you’re coming from, Git is more than most people need – but there are also times when I come across something I didn’t think I needed. The fact Git is a whole repository, for example, when I realise I need another branch or revert…. but I’m on a plane with no network connection.

    GitHub is also priceless: an app on my phone to track issues, and an app on my laptop which works perfectly, as far as I can tell. The website itself is excellent, and makes collaboration very easy. The only downside is the total lack of private repositories unless you’re willing to pay.

  97. Pingback: Dear git: STOP CHANGING DEFAULT BEHAVIOUR! | The Reinvigorated Programmer

  98. I love your comments and am an avid hater of all things git until I can type in open and save in my terminal to work on files.

  99. Pingback: Revisiting my issues with git, nine years on | The Reinvigorated Programmer

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.