Wednesday, April 14, 2021

Rant: Git is not a version control system. But you're going to use it as one anyways.

I can hear you saying it.

" You're wrong, Delphi Code Monkey, Git is a version control system.".

Hear me out.

Git is not a version control system, it's a directed acyclical graph management system that happens to be possible (sometimes) to do version control with.

Every time you find something Git can't do, that it ought to do, for all of the billion people who probably use it and know it well,  if you keep searching for ways, however torturous, to handle your issue, there is probably a way.

There is stashing, and submodules, branching, and merging, there are cherry picks, and there is rebasing, there are branching models and workflows like Git Flow.        There's recursive submodule hell.  There's local git cached state hell.  There's ignore hell.   There's Git's unix roots are showing on windows hell.
There's git config hell.    There's unable to check out a branch because of local changes, and yet git status shows no files have changed, hell.   If I sat here and thought back through the years of horrible things Git has done to me, one by one, I would probably scream.

There are a thousand fresh hells waiting for you.  A thousand inscrutable (but usually googleable) error messages.

Here's the worst of the Git hells.  Git lockin hell.  Once you choose Git,  well, it's Hotel California.  You can "check out" but you can never leave.   The world of software development is now, and probably always will be locked into some version of Git or other.

Git is not actually (much) of a version control system, but you're going to use it like it was, and you're going to learn to like it.

Update:  The point of this rant (and it mostly is just a ranty rant) isn't that you SHOULD NOT use Git, it's that the nature of Git is to expose all the guts to you, and to blow up with errors that are because the internals are in a bad place and Git leaves it for you to put Humpty Dumpty back together again,  and that you are going to do that a LOT when you live and work all day, especially in a team of 5+ people, with Git.    Perhaps if you are saying to yourself, "I don't have all these problems that other people talk about", it could be because (a) you're not using submodules, (b) you're not working with teams of 5+ comitters, and (c) you don't use a lot of branching, merging, rebasing, cherry-picking nor complex workflows like git-flow.


  1. Sorry, but I do not follow. How is git not a distributed version control system?

    1. It's a rant - you shouldn't take it literally.

    2. Uwe is right. It's just a rant, but it does have a point to make. The point is that when a tool has rough edges, as Git does, you will find that you need to build workarounds.

      People do this all the time, google the term "git porcelain" and "git wrappers". That means you can actually BUILD a better git on top of git, via workflow, tooling, scripting, and so on. IN fact, that is another possible blog post, a much more constructive and useful one.

      This one was just the ranty bit.

  2. Are you just ranting at the stumbling blocks in GIT, or do you define version control differently than I do?

    1. To me GIT feels like a version control SDK rather than a version control system. Nobody should be forced to use it directly, instead it should be used to build other version control systems that "just work". You shouldn't need to list a version control system on your resume as one of your major skills, it should be a tool your coworkers can teach you in 10 mins on your first day.

    2. The point is 55% ranty and 45% informational. Git solves a subset of the scope of the problem. The rest is left as an exercise for the user.

  3. Meanwhile life had just been great over here in the land of Mercurial until a year or so. With Bitbucket dropping Mercurial hosting there's no clear, safe choice for third party Mercurial hosting yet. Hopefully that changes soon and then I can go back to being a smug Mercurial advocate once again, saying things like "Mercurial is to Git as 1990s Delphi is to 1990s Visual Studio".

    1. I'm still using Mercurial (with subrepos) and it's pretty much just as bad as git, except fewer people use it now

    2. Submodules seem like a good idea until you construct a proof for their badness. The proof for their badness works as follows:

      1. Use submodules for a long time.

      2. Find that they cause you more problems than they are worth, and that it's now very hard to get rid of them.

      They are like Klingons, once they are in your airspace it's hard to get rid of them.

  4. Everything as expected. The first git commit:

    commit e83c5163316f89bfbde7d9ab23ca2e25604af29
    Author: Linus Torvalds
    Date: Thu Apr 7 15:13:13 2005 -0700
    Initial revision of "git", the information manager from hell