1. 27

And an equally short follow-up from 2017: Git, Graphs, and Software Engineering.

  1.  

  2. 6

    I once heard git described as a tool for constructing workflows. It’s the low-level tool used to construct higher-level workflows that you actually use in daily work, and this is by design. You don’t use “git” in daily work, you use “git + gitflow” or “git + whatever”, where the correct choice of “whatever” depends on your team size and various other constraints.

    Git’s porcelain commands, and especially their names, are a worthy object of scorn. Criticizing git as “GOTO,” however, because it’s so flexible, seems like a category error.

    1. 10

      I think the article’s aim is not to criticise (‘Git is as harmful as GOTO’), but to point out an opportunity (‘We can limit ourselves to a small number of easy-to-understand commit graph manipulations, like GOTO was superseded by a small number of well-understood flow control constructs’). In fact, its point might be quite narrow: ‘constrain which merges are allowed’. The author made “Today’s best practices” a hyperlink to Git Flow, so that points in the same direction of ‘constrain which merges you allow’

      Which lines up neatly with your point that ‘git is a tool for describing workflows’! The author’s recommendation, then, is to use the constrained workflows, not the tool that allows them all.

      A real-world example of a tool that enforces such a structure: Jane Street’s Iron manages their Mercurial monorepo as a tree of hierarchical features, and exposes two basic operations that to manage this feature hierarchy: rebase and release. Under the hood, ‘rebase’ means ‘merge the latest parent branch into the child’, and ‘release’ means ‘merge the child’s changes into the parent branch’.

      Come to think of it, the git-flow plugin is another example of a tool that only allows certain kinds of merges.

      (I do agree with you that Git’s interface is a dog’s breakfast. Furthermore, I am of the opinion the staging area must be destroyed.)

      1. 7

        I like the staging area. When doing new deveopment I’ll often do two, maybe three things are aren’t related and having the staging area is nice to isolate the changes into appropriate commits when unrelated changes are in the same file.

        1. 6

          My response to the staging area:

          https://news.ycombinator.com/item?id=18920430

          Newcomers to git often don’t like it, and I think they have a point.

          1. 2

            Note that this guy is also a mercurial developer. I think you should have mentioned it because people would know you have deep knowledge of versioning systems and it wouldn’t sound biased if someone found afterwards.

            1. 1

              Beg your pardon, which guy and who should have said what?

          2. 3

            I use both Mercurial and Git, and in both cases I find amending the last commit is functionally equivalent to adding to the staging area, without the need for an extra concept.

            If Git would not have the staging area, it could get rid of every command or flag that has to exist because the SA is separate from both tip commit and working dir. Off the tip of my HEAD :-P, it could deduplicate / unify

            • git add and git commit --amend
            • git add -p and git commit --amend --interactive
            • git reset, git reset --hard, and git checkout -- myfile
            • git diff, git diff --staged, and git log -p
            • git status: the ‘staged’ and ‘unstaged’ parts of its output
            1. 1

              Amending the last commit isn’t at all similar to changing the staging area. When you amend the last commit, you’re changing what is in the last commit. When you’re adding something to the staging area, you’re changing what will be the next commit.

              When you make some changes in your repository, you do not always want to actually commit all of them. That’s why there’s a staging area. You can skip it in git, using commands to commit while also adding all unstaged changes (commit -a), but it’s a bad idea. Every time I’ve tried this I’ve inevitably ended up with things I didn’t want getting added.

              The staging area forces you to consciously acknowledge every change that goes into your commits. That’s really important in my opinion. Everything in the commit is something a human has consciously decided to put there.

              1. 1

                Amending the last commit isn’t at all similar to changing the staging area. When you amend the last commit, you’re changing what is in the last commit. When you’re adding something to the staging area, you’re changing what will be the next commit.

                That’s exactly the similarity I’m getting at.

                • When you commit and then amend the last commit, you create a commit that contains what you want.
                • When you add to the staging area and then commit, you create a commit that contains what you want.
                1. 2

                  Literally everything you do in git is something that will eventually result in one or more commits being created. That doesn’t mean that git shouldn’t have all those other concepts and functionalities.

                  When you commit something then amend it, you’re doing something completely different to adding to the staging area and then committing. I genuinely am not sure how you could have used git and thought that these two concepts are the same thing…

      2. 3

        I disagree with the entire premise of these kinds of posts, because I think git is actually super intuitive. But the people that I know that are highly intelligent have never had any kind of problem using git. The only people that I know that have had trouble with it don’t bother to learn anything about it.

        1. 5

          I am regarded as something of a git guru at work. I know way more than the average developer about using git.

          I think it’s user interface is an abomination. Just because I can figure it out and do what I need to do doesn’t mean it’s a good tool.

          1. 3

            Okay, that’s your experience. But my experience is quite the opposite. I think its user interface is fantastic. When I try to use something like Mercurial, I find its user interface to be absolutely horrible. To get something like the staging area in git you need to enable various extensions, and even then you’re working with a bunch of commands all prefixed by ‘q’ or something, last I checked.

            Git is just easy in comparison. A bunch of simple orthogonal commands.

            1. 3

              Okay, that’s your experience. But my experience is quite the opposite.

              Your experiences and those of other people are not in opposition. They are both valid, and you must come to a worldview that explains them both, instead of choosing one over the other.

              So, how many explanations can you come up with where Git’s interface is easy for you, and difficult for others, even though you’re both smart?

              1. 2

                The Devil’s advocate would ask why doesn’t git stash list your stashes?

                I love Git to pieces and wouldn’t trade any of the “pick a commit from another branch into an interactive rebase” features for anything, but the interface should be more consistent.

                Every project I’ve seen that tries to make Git “easier” throws the infant out with the bath water by also dumbing it down. The extent of such a project should be limited to those small things.

                1. 1

                  The Devil’s advocate would ask why doesn’t git stash list your stashes?

                  git stash stashes, just like git commit commits and git push pushes.

                  1. 2

                    Fair enough, but then you need to know that git branch is special in many ways. It really doesn’t branch, you have to use the overloaded checkout for that.

                    I don’t personally have a problem with any of this, and there’s a little streak of vanity in me that likes it when I get asked about Git usage.

                    1. 1

                      Yeah git branch not branching is a bit silly. It’s not a big issue though

            2. 1

              I fully accept that you believe the user experience cannot be improved for you. But what makes you think it cannot be improved for other people while still keeping all the features you know and love?

            3. 1

              That makes me wonder when version control will have its structured revolution—when today’s best practices will be enforced rather than encouraged.

              Does the linked workflow really represent best practice? It feels needlessly complex to me.

              1. 2

                Git flow is definitely a practice and not unpopular.

                Sadly, I wish it weren’t for the reasons you outline. It’s hard to enforce, needs a lot of training and in general, the branching model isn’t the biggest problem. I’ve never seen it work the way it’s written down, too. Also, it’s emphasis on named branches (like feature/…) leads to some people feeling like they can make some branches very long-lived, the feature branches being a prime target for it. At best, people just rename master to develop and make develop a long-running branch, rarely deploying master…

              2. 1

                I think most people in practice do use a “structured” subset of git to manipulate the graph. Whenever git comes up it is usually in the context of how hard it is to learn and use properly. I used to agree until I went through this tutorial that showed all the basic git commands as operations on graphs.