Re: [PATCH] doc: pull: fix rebase=false documentation

[Felipe Contreras <felipe.contreras@gmail.com>]

Jeff King wrote:
> On Wed, Jul 21, 2021 at 08:24:25PM -0500, Felipe Contreras wrote:
> 
> > I'm not trashing the current behavior, I'm explaining what the consensus
> > is. I spent several man-days re-reading old threads, and this is the
> > consensus of what should happen:
> > 
> >   1. git pull              # merge HEAD into upstream
> >   2. git pull origin topic # merge topic into HEAD
> > 
> > Of the people that expressed an opinion, 100% of them stated that what
> > `git pull` does in the first case today is not desirable.
> 
> I did not participate in the threads you linked earlier, so I am
> probably not in that 100%. But you did use my name below:
> 
> > Yes, you are correct that if *everyone* followed the topic branch
> > workflow, everything would work correctly, but that's not what happens
> > in reality, in reality people do all kinds of workflows, and wrong
> > merges are pervasive.
> > 
> > Everyone--including Linus, Jeff, and you--agree that there's two
> > different ways of using `git pull`: integrator versus developer.
> > 
> > When a user is doing `git pull` to synchronize changes to push to the
> > same branch, that's a centralized two-way workflow, so he is acting both
> > as an integrator and as a developer, and it's in that particular case
> > that the order of the parents should be reversed. Everyone agrees on
> > that.
> > 
> > When the user the opposite explicitely: `git pull origin master`
> > Linus calls it a "back-merge" [1], and in that case the order of the
> > parents should not be reversed.
> 
> So I feel compelled to say now that I do not think that changing the
> order of parents for "git pull" is the obviously correct thing to do.

That's not the same as saying it's the wrong thing to do.

More importantly, while for you it might not be the obviously correct
thing to do, it should be obvious that there is a problem. Whether
reversing the parents in case #1 is the best solution or not is
debatable.

> And likewise, in the one thread I do remember participating in, I
> expressed something similar:
> 
>   https://lore.kernel.org/git/20140502214817.GA10801@sigill.intra.peff.net/

In that comment you mentioned that you were not against reversing the
order of the parents, but if we did, that it should done with a
configuration that the user explicitely turns on:

  I wanted to make one point: if we are going to do such a switch, let's
  please make it something the user explicitly turns on.

I am not against adding a configuration to reverse the parents only on
case #1. Additionally we could delineate a migration path that mentions
that in the future this will be default, although that can be done and
discussed later.

But the fact that there's a problem is not debatable.


Either way it's precisely because `git pull` is a command with so much
inertia that it's hard to change (although not impossible), that I
decided to create a new `git update` command whose whole purpose is to
implement case #1, which is intended for normal developers, not
integrators, and there the order of the parents is reversed by default.

-- 
Felipe Contreras