{"thread":{"id":"56162","subject":"git push --continue: yet another solution to the git pull problem","startedAt":"2021-07-26T16:40:30Z","lastAt":"2021-07-26T16:40:30Z","messageCount":1,"participants":["Felipe Contreras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"431200","messageId":"60fee4f6f2198_d0c208dd@natae.notmuch","threadId":"56162","inReplyTo":null,"subject":"git push --continue: yet another solution to the git pull problem","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-26T16:38:14Z","receivedAt":"2021-07-26T16:40:30Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"In order to understand that there's a problem with `git pull`, we need\nto understand that most users don't use git like us:\n\n  1. Many people follow trunk-based development [1]\n  2. 63% of people use a centralized workflow [2]\n\nIn these situations the developer will see the following message while\npushing:\n\n  To origin\n   ! [rejected]        master -> master (non-fast-forward)\n  error: failed to push some refs to 'origin'\n  hint: Updates were rejected because the tip of your current branch is behind\n  hint: its remote counterpart. Integrate the remote changes (e.g.\n  hint: 'git pull ...') before pushing again.\n  hint: See the 'Note about fast-forwards' in 'git push --help' for details.\n\nBut this particular integration should have the order of the parents\nreversed, as it has been discussed many times ([4] [5] [6]).\n\nIn order to fix this, we could have a push.autoSync configuration\nthat attempts to automatically do this synchronization, and once the user\nhas verified that the conflicts have been resolved correctly, and the\nmerge is correct:\n\n  git push --continue\n\nThis solves the issue of the order of the parents because it's only in\nthis particular case that everyone agrees the order of the parents\nshould be reversed.\n\nEven Junio has agreed.\n\nJunio C Hamano wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n> \n> >> But that does not necessarily mean swapping the parent order would\n> >> produce the history of a right shape, either, even for those with\n> >> the \"first-parent chain is the trunk\" worldview.\n> >\n> > Why not? Everyone who saw a problem agreed it would.\n> > \n> > Reversing the order of the parents creates a merge commit like so:\n> > \n> >   Y---X-+\n> >          \\\n> >   B---A---M  trunk\n> > \n> > Most git experts work with topic branches, and when you do that, you get\n> > the same thing:\n> > \n> >     topic\n> >       |\n> >       v\n> >   Y---X-+\n> >          \\\n> >   B---A---M  master\n> > \n> > If you merge topic to master, the first parent of the merge commit is A.\n> > \n> > If you do `git pull --reverse-parents` on a trunk-based workflow as\n> > above, you would get exactly the same shape of the history.\n> > \n> > How is it not the right shape?\n> \n> I gave detailed write-up in two discussion threads linked already in\n> this thread from 2013 and 2014; as I said, I do not think we want to\n> debate that as part of the discussion of this documentation fix.\n\nI already spent several man-days re-reading the discussions\nmultiple times, and I spent several man-hours re-reading them yet again\nto answer this mail. And what I see is that you agree in some situations\nthe order of the parents is wrong.\n\nIn this thread in 2013 you said that the obvious fix is to use a topic\nbranch workflow, but as I explained above, not everyone does, and we\ncan't force them to do that. They need a way to reverse the order of the\nparents, and you yourself were not oppossed:\n\n  I personally am not strongly opposed to a \"flip the heads\" option, if\n  implemented cleanly.\n\nhttps://lore.kernel.org/git/7vd2shheic.fsf@alter.siamese.dyndns.org/\n\nThere's many other instances in which you agree we make the merge in the\nwrong direction:\n\n  That is one case in which it is very clear that we are making a merge\n  in the wrong direction.\n\nhttps://lore.kernel.org/git/xmqqoazgaw0y.fsf@gitster.dls.corp.google.com/\n\n  I meant \"Introduce 'update' that lets integrate your history into that\n  from the remote, which is to integrate in a direction opposite from\n  how 'pull' does\".  \n\nhttps://lore.kernel.org/git/xmqqa9b2egcy.fsf@gitster.dls.corp.google.com/\n\n - Most people are not integrators, and letting \"git pull\" run on\n   their work based on a stale upstream to sync with an updated\n   upstream would create a merge in a wrong direction and letting\n   user continue on it.  We need to have a way to prevent this.\n\nhttps://lore.kernel.org/git/7vbnvhil5x.fsf@alter.siamese.dyndns.org/\n\n  The issue we are discussing with \"git pull\" is that if a non\n  integrator does a \"git pull\" from the upstream, in order to push the\n  result of integrating the local work with it back to the upstream,\n  by default \"git pull\" creates a merge in a direction that is wrong\n  when seen in the \"first-parent chain is the trunk\" point of view.\n\nhttps://lore.kernel.org/git/xmqqbnvgasib.fsf@gitster.dls.corp.google.com/\n\n  To me, the problem sounds like:\n\n      Tutorials of Git often says \"use 'git pull' to catch up your\n      branch with your upstream work and then 'git push' back\" (and\n      worse yet, 'git push' that does not fast-forward suggests doing\n      so), but 'git pull' that creates a merge in a wrong direction is\n      not the right thing for many people.\n\nhttps://lore.kernel.org/git/xmqqoazgaw0y.fsf@gitster.dls.corp.google.com/\n\n\nOf course not all merges should be done on the opposite direction, only\nthe final merge that is meant to integrate the current branch into\nupstream. That's what `git pull --continue` would do.\n\nThat would solve the issue for all the people that work on trunk-based\ndevelopment, or centralized workflows.\n\nIf a hypothetical user wants to do back-merges from \"origin/master\" to his\n\"master\" he can manually do `git pull` for those, and the order will be\nin the traditional order, so the history would *never* be in the wrong\nshape.\n\nOf course, we don't need to wait for `git pull --continue` to be\nimplemented, we can start telling users that after `git push` they\nshould run `git update` instead of `git pull`, and the former will\nreverse the order of the parents correctly.\n\nSo users can do `git pull` for back-merges, and `git update` to\nsynchronize and before pushing the changes back to master.\n\nSo I repeat my question: how would this not create the right shape?\n\nCheers.\n\n[1] https://trunkbaseddevelopment.com/\n[2] https://survs.com/report/nz2odu1spl\n[3] https://lore.kernel.org/git/20130522115042.GA20649@inner.h.apk.li/\n[4] https://lore.kernel.org/git/4ay6w9i74cygt6ii1b0db7wg.1398433713382@email.android.com/\n[5] https://lore.kernel.org/git/5363BB9F.40102@xiplink.com/\n\n-- \nFelipe Contreras\n"}]}