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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxx/ 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx/ 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx/ - 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@xxxxxxxxxxxxxxxxxxxxxxxx/ 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx/ 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx/ 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@xxxxxxxxxxxxxx/ [4] https://lore.kernel.org/git/4ay6w9i74cygt6ii1b0db7wg.1398433713382@xxxxxxxxxxxxxxxxx/ [5] https://lore.kernel.org/git/5363BB9F.40102@xxxxxxxxxxx/ -- Felipe Contreras
