Revisiting my issues with git, nine years on

Nine years ago, I wrote Git is a Harrier Jump Jet. And not in a good way, then followed it up with Still hatin’ on git: now with added Actual Reasons! Both posts evidently resonated with a lot of people, but also attracted a lot of constructive disagreement.

Prodded by a new comment from MiB this morning, I found myself writing a response that I think is worth reproducing and amplifying here.

The problem with git is that it’s complex, and that is at least in part because it’s trying to solve a complex problem.

I don’t think anyone’s ever argued that complex problems must always necessarily have complex solutions — there is such a thing as cutting the Gordian Knot. But anything that’s complicated is that way due to a combination of two factors: the inherent complexity of the problem to be solved, and “wasted” complexity that is introduced by a suboptimal solution.

I started out thinking that git-as-solution-to-version-control was mostly the second kind of complexity. It certainly introduces some of that — not all its decisions are defensible — but I have increasingly come around to the perspective that most of the complexity is real, and inherent in the problem we’re trying to solve. That said, people who don’t need to solve the whole problem (multiple teams distributed in time and space, contributing potentially conflicting change-sets to a codebase that must both move forwards into new versions and maintain bugfix releases of older versions) then you don’t need the whole solution.

Git is far from perfect — there are still plenty of occasions when I get a checkout into a state I don’t understand, and end up having to take off and nuke the whole checkout from orbit. But it genuinely is very very powerful (especially when complemented by GitHub and similar tools), and when you need that kind of power it’s genuinely inevitable that you’re going to need to deal with some complexity, just as a food processor is more complex to use than a knife.

(And of course “This should be simple, we don’t need all this complexity, we should just get rid of it all” is exactly the kind of thinking got us Brexit and the current no-deal insanity.)

Advertisement

13 responses to “Revisiting my issues with git, nine years on

  1. I think that Git the plumbing is pretty good. A DAG of commits is an excellent base to build on.

    Git the interface is terrible for anything non-trivial, and I am delighted that there are excellent tools to let me not use it 99% of the time.

  2. It does feel rather as though the various command-line git this and git that commands started life as test-harnesses to exercise the plumbing, and got released into the wild by accident. “Life will find a way.”

  3. @andrewducker My feelings exactly. I swear by Smartgit and rarely have to touch the git command line.

  4. I don’t know git at all. My reaction to what you’re saying is initially, “that sounds like a load of suck. I really don’t like what I’m hearing about.” But thinking for a moment, that was also my reaction to Unix, which was definitely a hate-hate relationship in the early days. But I could see something there and persisted, even just as an intellectual exercise, until I “got it” (it takes me a while to get things: maybe it’s because of the autism, or maybe it’s just because I’m difficult). And suddenly it was all worthwhile, and has been ever since. And in hindsight the alternative (though actually VMS) might have been Windows. *shudder* Was it worth the trauma? In its case, absolutely. But I guess that’s always the pertinent question.

  5. I think the Unix analogy is pretty strong, actually.

  6. I’ve never used this thing called ‘git’. I can imagine there are situations in which it is indispensable. I hope I never find myself in one.

  7. Git at least solves problems that systems like RCS ignores, and systems like CVS amplified the suckage beyond belief. git has a lot of issues, but its fundamental ‘everythings a repo, you can push and pull, and name your branches and tags’ works pretty well. Until it doesn’t :)

  8. “Solves problems that systems like RCS ignores” is the very essence of what’s going on here. It doesn’t solve its problems perfectly, but it addresses them — which is more than RCS or CVS do. This has become more and more apparent to me over the last few years. (It’s nice to still be learning such things in my fifties.)

  9. Its also good they didn’t try to just retrofit a paper bag onto the side of systems like RCS.. it does its job pretty well, being an in-directory solution; now that git exists, RCS nearly has no function at all anymore. CVS tries to be the push-to-remote-repo solution, but it still can’t safely deal with large files or binary files, or ‘holey files’ and other oddballs .. but not dealing well with binary files? Thats unforgivable in civilized society :) Git is like a modern filesystem.. not perfect, and a lot of weird edge cases.. but doing a lot of things right, and you just need a good UI on top (be it CLI or GUI or whatever.)

    All is well until the rebase happens…. :)

  10. GIT is a nightmare, the number of buggered up repos and mad checkouts I’ve had to deal with over the years has turned me squarely agin’ it. I use Tortoise HG (Mercurial) for my personal stuff. In my current job I’m using SVN and while I don’t mind it I’d definitely like to switch to HG. The company wants to switch to a distributed system and as there’s only a small team I might be able to beat them into submission and get to use HG. Linus is reported as saying you have to be smart to use git but I’m an average guy (and as we all know the average guy is stupid). Actually, I’m not that stupid, but I am lazy and git has always been too much work whereas I learnt HG in two days 10 years ago and only occasionally do I have to look at the help.

    Linus should listen to George…

    “Think of how stupid the average person is, and realize half of them are stupider than that.” – Geroge Carlin.

  11. Never having used Hg, I’m not in a position to compare it with git. It does seem, from others’ comments, though, that it would be the obvious alternative. Equivalently powerful, maybe more elegant.

  12. For nearly a decade I’ve managed to avoid git, but the increasing migration of my job into cloud solutions and Microsoft’s insistence upon using github for every damn thing means that I am now having to deal with it and I have just spent an hour trying to get an answer to the question “how do I get just the file that I need from github and not the 400 other files in the repository that I don’t want?” The fact that it took so long to find that the answer is essentially “you can’t because no-one ever wants just one file and if you think that you do then you’re doing it wrong” shows just how bad the state of git’s usability still is. The problem is that the solution addresses what the designer(s) think the problem space is rather than what actual users will inevitably want to do, because I do want just one file and I don’t need all of the others that I ended up getting anyway and then deleting.

  13. Git archive will do what you want, albeit you’ll get the file (s) inside a zip file.

    (Use the “remote” parameter)

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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.