1. 23
  1.  

  2. 15

    I have my own gripes about the awkwardness of git pull but goodness this is a … long, long post with a lot of inconsequential banter in the middle that makes it truly difficult to root for the author in this.

    1. 16

      This blog post was sent out on the git mailing list. https://public-inbox.org/git/60e325175e689_1baed32081c@natae.notmuch/T/#u

      This is mostly a git hacker attempting to justify a change to other git hackers. Documenting the other attempts and why they didn’t get in is the primary goal.

      That prevents the same mistakes from being made, and the patches being rejected for the same reasons.

      The audience for the post is git hackers needing a refresher on past attempts at improving the situation, not internet randos looking for an entertaining grouse on why git pull sucks.

      1. 7

        I’m glad I’m not the only person who felt this way. There’s an awful lot of specific focus on the exact people who took place in the discussion and a lot less effective summarizing of the discussion. The author talks about how they used to be very abrasive, and I’m not getting the sense that they’ve moved much past it. It feels like there’s a lot of implicit axe-grinding happening here.

        1. 2

          I’m not sure what the author’s goals are but highlighting these kinds of community issues might also be valuable.

        2. 5

          The author seems frustrated and explains why.

          The purpose of the post is to “document all the discussions related to git pull and its default mode,” so it makes sense there would be a lot of inconsequential banter. As the author notes, there hasn’t been a consequence to all the banter! 🥲

        3. 4

          Working in teams is so painful

          1. 3

            A normal developer would want to do the opposite: to merge his “master” (C) to the upstream “origin/master” (B), so the first parent is “origin/master” (B). This is not a trivial thing. The order of the parents completely changes how history is visualized, and even traversed, plus it’s important when resolving conflicts, along many other things.

            Junio’s response:

            Don’t do that, then.

            Ah, classic open source discussions.

            1. 1

              This really reminds me of old times of working on openstack nova. Some patches were just a soul destroying experience.

              But I feel like now I understand why git interface is as bad as it is. I’m still going for git’s version of sequoia-pgp effort one day.

              1. 1

                What are some examples where the merge order used by git pull matters?

                1. 2

                  A lot of times, people will recommend --first-parent as a way to track the development of an individual branch (since when you merge two branches, git doesn’t explicitly track which parent belongs to which branch). This breaks if the merge order gets messed up.

                  1. 1

                    Thanks, that makes sense. I think he also said it could affect the conflict resolution somehow.