git push --continue: yet another solution to the git pull problem

git push --continue: yet another solution to the git pull problem

[Felipe Contreras]

In order to understand that there's a problem with `git pull`, we need
to understand that most users don't use git like us:

  1. Many people follow trunk-based development [1]
  2. 63% of people use a centralized workflow [2]

In these situations the developer will see the following message while
pushing:

  To origin
   ! [rejected]        master -> master (non-fast-forward)
  error: failed to push some refs to 'origin'
  hint: Updates were rejected because the tip of your current branch is behind
  hint: its remote counterpart. Integrate the remote changes (e.g.
  hint: 'git pull ...') before pushing again.
  hint: See the 'Note about fast-forwards' in 'git push --help' for details.

But this particular integration should have the order of the parents
reversed, as it has been discussed many times ([4] [5] [6]).

In order to fix this, we could have a push.autoSync configuration
that attempts to automatically do this synchronization, and once the user
has verified that the conflicts have been resolved correctly, and the
merge is correct:

  git push --continue

This solves the issue of the order of the parents because it's only in
this particular case that everyone agrees the order of the parents
should be reversed.

Even Junio has agreed.

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> >> But that does not necessarily mean swapping the parent order would
> >> produce the history of a right shape, either, even for those with
> >> the "first-parent chain is the trunk" worldview.
> >
> > Why not? Everyone who saw a problem agreed it would.
> > 
> > Reversing the order of the parents creates a merge commit like so:
> > 
> >   Y---X-+
> >          \
> >   B---A---M  trunk
> > 
> > Most git experts work with topic branches, and when you do that, you get
> > the same thing:
> > 
> >     topic
> >       |
> >       v
> >   Y---X-+
> >          \
> >   B---A---M  master
> > 
> > If you merge topic to master, the first parent of the merge commit is A.
> > 
> > If you do `git pull --reverse-parents` on a trunk-based workflow as
> > above, you would get exactly the same shape of the history.
> > 
> > How is it not the right shape?
> 
> I gave detailed write-up in two discussion threads linked already in
> this thread from 2013 and 2014; as I said, I do not think we want to
> debate that as part of the discussion of this documentation fix.

I already spent several man-days re-reading the discussions
multiple times, and I spent several man-hours re-reading them yet again
to answer this mail. And what I see is that you agree in some situations
the order of the parents is wrong.

In this thread in 2013 you said that the obvious fix is to use a topic
branch workflow, but as I explained above, not everyone does, and we
can't force them to do that. They need a way to reverse the order of the
parents, and you yourself were not oppossed:

  I personally am not strongly opposed to a "flip the heads" option, if
  implemented cleanly.

https://lore.kernel.org/git/7vd2shheic.fsf@alter.siamese.dyndns.org/

There's many other instances in which you agree we make the merge in the
wrong direction:

  That is one case in which it is very clear that we are making a merge
  in the wrong direction.

https://lore.kernel.org/git/xmqqoazgaw0y.fsf@gitster.dls.corp.google.com/

  I meant "Introduce 'update' that lets integrate your history into that
  from the remote, which is to integrate in a direction opposite from
  how 'pull' does".  

https://lore.kernel.org/git/xmqqa9b2egcy.fsf@gitster.dls.corp.google.com/

 - Most people are not integrators, and letting "git pull" run on
   their work based on a stale upstream to sync with an updated
   upstream would create a merge in a wrong direction and letting
   user continue on it.  We need to have a way to prevent this.

https://lore.kernel.org/git/7vbnvhil5x.fsf@alter.siamese.dyndns.org/

  The issue we are discussing with "git pull" is that if a non
  integrator does a "git pull" from the upstream, in order to push the
  result of integrating the local work with it back to the upstream,
  by default "git pull" creates a merge in a direction that is wrong
  when seen in the "first-parent chain is the trunk" point of view.

https://lore.kernel.org/git/xmqqbnvgasib.fsf@gitster.dls.corp.google.com/

  To me, the problem sounds like:

      Tutorials of Git often says "use 'git pull' to catch up your
      branch with your upstream work and then 'git push' back" (and
      worse yet, 'git push' that does not fast-forward suggests doing
      so), but 'git pull' that creates a merge in a wrong direction is
      not the right thing for many people.

https://lore.kernel.org/git/xmqqoazgaw0y.fsf@gitster.dls.corp.google.com/


Of course not all merges should be done on the opposite direction, only
the final merge that is meant to integrate the current branch into
upstream. That's what `git pull --continue` would do.

That would solve the issue for all the people that work on trunk-based
development, or centralized workflows.

If a hypothetical user wants to do back-merges from "origin/master" to his
"master" he can manually do `git pull` for those, and the order will be
in the traditional order, so the history would *never* be in the wrong
shape.

Of course, we don't need to wait for `git pull --continue` to be
implemented, we can start telling users that after `git push` they
should run `git update` instead of `git pull`, and the former will
reverse the order of the parents correctly.

So users can do `git pull` for back-merges, and `git update` to
synchronize and before pushing the changes back to master.

So I repeat my question: how would this not create the right shape?

Cheers.

[1] https://trunkbaseddevelopment.com/
[2] https://survs.com/report/nz2odu1spl
[3] https://lore.kernel.org/git/20130522115042.GA20649@inner.h.apk.li/
[4] https://lore.kernel.org/git/4ay6w9i74cygt6ii1b0db7wg.1398433713382@email.android.com/
[5] https://lore.kernel.org/git/5363BB9F.40102@xiplink.com/

-- 
Felipe Contreras