{"thread":{"id":"56138","subject":"[PATCH] doc: pull: fix rebase=false documentation","startedAt":"2021-07-21T22:15:52Z","lastAt":"2021-07-24T03:56:59Z","messageCount":12,"participants":["Felipe Contreras","Junio C Hamano","Jeff King","Philip Oakley"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"430798","messageId":"20210721221545.1878514-1-felipe.contreras@gmail.com","threadId":"56138","inReplyTo":null,"subject":"[PATCH] doc: pull: fix rebase=false documentation","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-21T22:15:45Z","receivedAt":"2021-07-21T22:15:52Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"The behavior of --rebase=false is obviously wrong (as has been discussed\nin big threads before [1] [2]): we want our users to merge their current\nbranch into the upstream branch, but this is not what the code is\ncurrently doing; it does the *opposite*.\n\nFix the documentation so that we explain what the code actually does,\nnot what we wish it did.\n\n[1] https://lore.kernel.org/git/20130522115042.GA20649@inner.h.apk.li/\n[2] https://lore.kernel.org/git/4ay6w9i74cygt6ii1b0db7wg.1398433713382@email.android.com/\n\nCc: Stephen Haberman \nSigned-off-by: Felipe Contreras \n---\n Documentation/git-pull.txt | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex 5c3fb67c01..7f4b2d1982 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -117,7 +117,7 @@ When set to `preserve` (deprecated in favor of `merges`), rebase with the\n `--preserve-merges` option passed to `git rebase` so that locally created\n merge commits will not be flattened.\n +\n-When false, merge the current branch into the upstream branch.\n+When false, merge the upstream branch into the current branch.\n +\n When `interactive`, enable the interactive mode of rebase.\n +\n-- \n2.32.0.40.gb9b36f9b52\n\n"},{"id":"430832","messageId":"xmqqy29z9r94.fsf@gitster.g","threadId":"56138","inReplyTo":"20210721221545.1878514-1-felipe.contreras@gmail.com","subject":"Re: [PATCH] doc: pull: fix rebase=false documentation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-21T23:33:27Z","receivedAt":"2021-07-21T23:33:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\n> index 5c3fb67c01..7f4b2d1982 100644\n> --- a/Documentation/git-pull.txt\n> +++ b/Documentation/git-pull.txt\n> @@ -117,7 +117,7 @@ When set to `preserve` (deprecated in favor of `merges`), rebase with the\n> `--preserve-merges` option passed to `git rebase` so that locally created\n> merge commits will not be flattened.\n> +\n> -When false, merge the current branch into the upstream branch.\n> +When false, merge the upstream branch into the current branch.\n> +\n> When `interactive`, enable the interactive mode of rebase.\n> +\n\nLooks correct. Will queue. Thanks.\n"},{"id":"430860","messageId":"xmqqtukn9p0g.fsf@gitster.g","threadId":"56138","inReplyTo":"xmqqy29z9r94.fsf@gitster.g","subject":"Re: [PATCH] doc: pull: fix rebase=false documentation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-22T00:21:51Z","receivedAt":"2021-07-22T00:21:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Felipe Contreras writes:\n>\n>> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\n>> index 5c3fb67c01..7f4b2d1982 100644\n>> --- a/Documentation/git-pull.txt\n>> +++ b/Documentation/git-pull.txt\n>> @@ -117,7 +117,7 @@ When set to `preserve` (deprecated in favor of `merges`), rebase with the\n>> `--preserve-merges` option passed to `git rebase` so that locally created\n>> merge commits will not be flattened.\n>> +\n>> -When false, merge the current branch into the upstream branch.\n>> +When false, merge the upstream branch into the current branch.\n>> +\n>> When `interactive`, enable the interactive mode of rebase.\n>> +\n>\n> Looks correct. Will queue. Thanks.\n\nBy the way, I'll update the proposed log message to say only that\nthe documentation needs to be fixed as it does not say what the\ncommand does. We should be able to fix the inaccuracies in the\ndocumentation quickly without advocating different behaviour or\ntrashing the current behaviour in the proposed log message.\n\nI also happen to think that \"flipping the merge order\" is not a good\nthing to do anyway [*1*]; keeping the log message to state just \"the\ndescription does not reflect reality-fix it\" has the added benefit\nthat we do not have to debate it.\n\n\n[Footnote]\n\n*1* https://public-inbox.org/git/7vd2shheic.fsf@alter.siamese.dyndns.org/\n"},{"id":"430861","messageId":"60f8c8c92a215_1d0abb20859@natae.notmuch","threadId":"56138","inReplyTo":"xmqqtukn9p0g.fsf@gitster.g","subject":"Re: [PATCH] doc: pull: fix rebase=false documentation","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-22T01:24:25Z","receivedAt":"2021-07-22T01:24:30Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Junio C Hamano writes:\n> > Felipe Contreras writes:\n> >\n> >> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\n> >> index 5c3fb67c01..7f4b2d1982 100644\n> >> --- a/Documentation/git-pull.txt\n> >> +++ b/Documentation/git-pull.txt\n> >> @@ -117,7 +117,7 @@ When set to `preserve` (deprecated in favor of `merges`), rebase with the\n> >> `--preserve-merges` option passed to `git rebase` so that locally created\n> >> merge commits will not be flattened.\n> >> +\n> >> -When false, merge the current branch into the upstream branch.\n> >> +When false, merge the upstream branch into the current branch.\n> >> +\n> >> When `interactive`, enable the interactive mode of rebase.\n> >> +\n> >\n> > Looks correct. Will queue. Thanks.\n> \n> By the way, I'll update the proposed log message to say only that\n> the documentation needs to be fixed as it does not say what the\n> command does.\n\nFine by me, although I'd appreciate if you minimize the use of your\nwords and maximize the use of mine.\n\n The documentation says --rebase=false merges our current branch into\n the upstream branch, and while many people think that's what should\n happen, that's not what actually happens; it's the *opposite*.\n\n Fix the documentation so that we explain what the code actually does.\n\n> We should be able to fix the inaccuracies in the\n> documentation quickly without advocating different behaviour or\n> trashing the current behaviour in the proposed log message.\n\nI'm not trashing the current behavior, I'm explaining what the consensus\nis. I spent several man-days re-reading old threads, and this is the\nconsensus of what should happen:\n\n 1. git pull # merge HEAD into upstream\n 2. git pull origin topic # merge topic into HEAD\n\nOf the people that expressed an opinion, 100% of them stated that what\n`git pull` does in the first case today is not desirable.\n\n> I also happen to think that \"flipping the merge order\" is not a good\n> thing to do anyway [*1*]; keeping the log message to state just \"the\n> description does not reflect reality-fix it\" has the added benefit\n> that we do not have to debate it.\n\nBut people have spent many hours debating it already.\n\nYes, you are correct that if *everyone* followed the topic branch\nworkflow, everything would work correctly, but that's not what happens\nin reality, in reality people do all kinds of workflows, and wrong\nmerges are pervasive.\n\nEveryone--including Linus, Jeff, and you--agree that there's two\ndifferent ways of using `git pull`: integrator versus developer.\n\nWhen a user is doing `git pull` to synchronize changes to push to the\nsame branch, that's a centralized two-way workflow, so he is acting both\nas an integrator and as a developer, and it's in that particular case\nthat the order of the parents should be reversed. Everyone agrees on\nthat.\n\nWhen the user the opposite explicitely: `git pull origin master`\nLinus calls it a \"back-merge\" [1], and in that case the order of the\nparents should not be reversed.\n\nThis has already been discussed many times, and the problem remains.\n\n[1] https://lore.kernel.org/git/CA+55aFwM0vy+pw-Xv=gA19ULMwAXNPhdO3qR5A3hkMrZKJFNSQ@mail.gmail.com/\n\n-- \nFelipe Contreras\n"},{"id":"430985","messageId":"YPpwIazVxL4GoLbC@coredump.intra.peff.net","threadId":"56138","inReplyTo":"60f8c8c92a215_1d0abb20859@natae.notmuch","subject":"Re: [PATCH] doc: pull: fix rebase=false documentation","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-07-23T07:30:41Z","receivedAt":"2021-07-23T07:30:44Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 21, 2021 at 08:24:25PM -0500, Felipe Contreras wrote:\n\n> I'm not trashing the current behavior, I'm explaining what the consensus\n> is. I spent several man-days re-reading old threads, and this is the\n> consensus of what should happen:\n> \n> 1. git pull # merge HEAD into upstream\n> 2. git pull origin topic # merge topic into HEAD\n> \n> Of the people that expressed an opinion, 100% of them stated that what\n> `git pull` does in the first case today is not desirable.\n\nI did not participate in the threads you linked earlier, so I am\nprobably not in that 100%. But you did use my name below:\n\n> Yes, you are correct that if *everyone* followed the topic branch\n> workflow, everything would work correctly, but that's not what happens\n> in reality, in reality people do all kinds of workflows, and wrong\n> merges are pervasive.\n> \n> Everyone--including Linus, Jeff, and you--agree that there's two\n> different ways of using `git pull`: integrator versus developer.\n> \n> When a user is doing `git pull` to synchronize changes to push to the\n> same branch, that's a centralized two-way workflow, so he is acting both\n> as an integrator and as a developer, and it's in that particular case\n> that the order of the parents should be reversed. Everyone agrees on\n> that.\n> \n> When the user the opposite explicitely: `git pull origin master`\n> Linus calls it a \"back-merge\" [1], and in that case the order of the\n> parents should not be reversed.\n\nSo I feel compelled to say now that I do not think that changing the\norder of parents for \"git pull\" is the obviously correct thing to do.\nAnd likewise, in the one thread I do remember participating in, I\nexpressed something similar:\n\n https://lore.kernel.org/git/20140502214817.GA10801@sigill.intra.peff.net/\n\n-Peff\n"},{"id":"431017","messageId":"9cb70776-8684-9d1e-e4c5-188c6c19fdc7@iee.email","threadId":"56138","inReplyTo":"YPpwIazVxL4GoLbC@coredump.intra.peff.net","subject":"Re: [PATCH] doc: pull: fix rebase=false documentation","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-07-23T10:05:08Z","receivedAt":"2021-07-23T10:05:47Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 23/07/2021 08:30, Jeff King wrote:\n> On Wed, Jul 21, 2021 at 08:24:25PM -0500, Felipe Contreras wrote:\n>\n>> I'm not trashing the current behavior, I'm explaining what the consensus\n>> is. I spent several man-days re-reading old threads, and this is the\n>> consensus of what should happen:\n>>\n>> 1. git pull # merge HEAD into upstream\n>> 2. git pull origin topic # merge topic into HEAD\n>>\n>> Of the people that expressed an opinion, 100% of them stated that what\n>> `git pull` does in the first case today is not desirable.\n> I did not participate in the threads you linked earlier, so I am\n> probably not in that 100%. But you did use my name below:\n>\n>> Yes, you are correct that if *everyone* followed the topic branch\n>> workflow, everything would work correctly, but that's not what happens\n>> in reality, in reality people do all kinds of workflows, and wrong\n>> merges are pervasive.\n>>\n>> Everyone--including Linus, Jeff, and you--agree that there's two\n>> different ways of using `git pull`: integrator versus developer.\n>>\n>> When a user is doing `git pull` to synchronize changes to push to the\n>> same branch, that's a centralized two-way workflow, so he is acting both\n>> as an integrator and as a developer, and it's in that particular case\n>> that the order of the parents should be reversed. Everyone agrees on\n>> that.\n>>\n>> When the user the opposite explicitely: `git pull origin master`\n>> Linus calls it a \"back-merge\" [1], and in that case the order of the\n>> parents should not be reversed.\n> So I feel compelled to say now that I do not think that changing the\n> order of parents for \"git pull\" is the obviously correct thing to do.\nWhile I never `pull` because it's not right for me as a 'contributor', I\ndo agree that the default 'maintainer' view of `pull` will need to be\nretained for long term backward compatibility.\n\nWhat I have rarely seen in the discussion is explanation that is based\non workflow style, though the potential `update` command (1) may break\nsome of the deadlock about the direction of 'pull requests', and\npossibly confusion regarding the location of the 'golden' publish repo.\n\n(1) there are a lot of 'update' commands floating about, esp on Git for\nWindows. If there is a suitably named `update` command to do the `pull\n--contributor` merge-ff swap then many of the issues could fade away.\n\n> And likewise, in the one thread I do remember participating in, I\n> expressed something similar:\n>\n> https://lore.kernel.org/git/20140502214817.GA10801@sigill.intra.peff.net/\n>\n> -Peff\n--\nPhilip\n"},{"id":"431043","messageId":"xmqqwnphowdx.fsf@gitster.g","threadId":"56138","inReplyTo":"YPpwIazVxL4GoLbC@coredump.intra.peff.net","subject":"Re: [PATCH] doc: pull: fix rebase=false documentation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-23T15:58:02Z","receivedAt":"2021-07-23T15:58:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> So I feel compelled to say now that I do not think that changing the\n> order of parents for \"git pull\" is the obviously correct thing to do.\n> And likewise, in the one thread I do remember participating in, I\n> expressed something similar:\n>\n> https://lore.kernel.org/git/20140502214817.GA10801@sigill.intra.peff.net/\n\nThanks for the link. Many articles in the thread are repeating the\nsame opinion over and over (and later even descend into ad-hominem\nattacks) and it is not worth anybody's time to read all of them, but\nI found that there still were some gems.\n\nIn an worldview where the first-parent chain is the trunk history,\nmerging in the upstream where you push back to into your working\nrepository where your new work is happening as the second parent\nbefore pushing it back would obviously make the history that used to\nbe trunk to lose the first-parent-ness at that point. And if you\nask if I just said is correct, everybody would say it is. So there\nis a concensus that the result of \"git pull upstream main\" becomes\na wrong shape for people in one workflow.\n\nBut that does not necessarily mean swapping the parent order would\nproduce the history of a right shape, either, even for those with\nthe \"first-parent chain is the trunk\" worldview.\n"},{"id":"431050","messageId":"60faf00444122_defb208cb@natae.notmuch","threadId":"56138","inReplyTo":"YPpwIazVxL4GoLbC@coredump.intra.peff.net","subject":"Re: [PATCH] doc: pull: fix rebase=false documentation","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-23T16:36:20Z","receivedAt":"2021-07-23T16:36:27Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Wed, Jul 21, 2021 at 08:24:25PM -0500, Felipe Contreras wrote:\n> \n> > I'm not trashing the current behavior, I'm explaining what the consensus\n> > is. I spent several man-days re-reading old threads, and this is the\n> > consensus of what should happen:\n> > \n> > 1. git pull # merge HEAD into upstream\n> > 2. git pull origin topic # merge topic into HEAD\n> > \n> > Of the people that expressed an opinion, 100% of them stated that what\n> > `git pull` does in the first case today is not desirable.\n> \n> I did not participate in the threads you linked earlier, so I am\n> probably not in that 100%. But you did use my name below:\n> \n> > Yes, you are correct that if *everyone* followed the topic branch\n> > workflow, everything would work correctly, but that's not what happens\n> > in reality, in reality people do all kinds of workflows, and wrong\n> > merges are pervasive.\n> > \n> > Everyone--including Linus, Jeff, and you--agree that there's two\n> > different ways of using `git pull`: integrator versus developer.\n> > \n> > When a user is doing `git pull` to synchronize changes to push to the\n> > same branch, that's a centralized two-way workflow, so he is acting both\n> > as an integrator and as a developer, and it's in that particular case\n> > that the order of the parents should be reversed. Everyone agrees on\n> > that.\n> > \n> > When the user the opposite explicitely: `git pull origin master`\n> > Linus calls it a \"back-merge\" [1], and in that case the order of the\n> > parents should not be reversed.\n> \n> So I feel compelled to say now that I do not think that changing the\n> order of parents for \"git pull\" is the obviously correct thing to do.\n\nThat's not the same as saying it's the wrong thing to do.\n\nMore importantly, while for you it might not be the obviously correct\nthing to do, it should be obvious that there is a problem. Whether\nreversing the parents in case #1 is the best solution or not is\ndebatable.\n\n> And likewise, in the one thread I do remember participating in, I\n> expressed something similar:\n> \n> https://lore.kernel.org/git/20140502214817.GA10801@sigill.intra.peff.net/\n\nIn that comment you mentioned that you were not against reversing the\norder of the parents, but if we did, that it should done with a\nconfiguration that the user explicitely turns on:\n\n I wanted to make one point: if we are going to do such a switch, let's\n please make it something the user explicitly turns on.\n\nI am not against adding a configuration to reverse the parents only on\ncase #1. Additionally we could delineate a migration path that mentions\nthat in the future this will be default, although that can be done and\ndiscussed later.\n\nBut the fact that there's a problem is not debatable.\n\n\nEither way it's precisely because `git pull` is a command with so much\ninertia that it's hard to change (although not impossible), that I\ndecided to create a new `git update` command whose whole purpose is to\nimplement case #1, which is intended for normal developers, not\nintegrators, and there the order of the parents is reversed by default.\n\n-- \nFelipe Contreras\n"},{"id":"431055","messageId":"60faf46153f62_defb208aa@natae.notmuch","threadId":"56138","inReplyTo":"9cb70776-8684-9d1e-e4c5-188c6c19fdc7@iee.email","subject":"Re: [PATCH] doc: pull: fix rebase=false documentation","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-23T16:54:57Z","receivedAt":"2021-07-23T16:55:06Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philip Oakley wrote:\n> On 23/07/2021 08:30, Jeff King wrote:\n> > On Wed, Jul 21, 2021 at 08:24:25PM -0500, Felipe Contreras wrote:\n> >\n> >> I'm not trashing the current behavior, I'm explaining what the consensus\n> >> is. I spent several man-days re-reading old threads, and this is the\n> >> consensus of what should happen:\n> >>\n> >> 1. git pull # merge HEAD into upstream\n> >> 2. git pull origin topic # merge topic into HEAD\n> >>\n> >> Of the people that expressed an opinion, 100% of them stated that what\n> >> `git pull` does in the first case today is not desirable.\n> > I did not participate in the threads you linked earlier, so I am\n> > probably not in that 100%. But you did use my name below:\n> >\n> >> Yes, you are correct that if *everyone* followed the topic branch\n> >> workflow, everything would work correctly, but that's not what happens\n> >> in reality, in reality people do all kinds of workflows, and wrong\n> >> merges are pervasive.\n> >>\n> >> Everyone--including Linus, Jeff, and you--agree that there's two\n> >> different ways of using `git pull`: integrator versus developer.\n> >>\n> >> When a user is doing `git pull` to synchronize changes to push to the\n> >> same branch, that's a centralized two-way workflow, so he is acting both\n> >> as an integrator and as a developer, and it's in that particular case\n> >> that the order of the parents should be reversed. Everyone agrees on\n> >> that.\n> >>\n> >> When the user the opposite explicitely: `git pull origin master`\n> >> Linus calls it a \"back-merge\" [1], and in that case the order of the\n> >> parents should not be reversed.\n> > So I feel compelled to say now that I do not think that changing the\n> > order of parents for \"git pull\" is the obviously correct thing to do.\n> While I never `pull` because it's not right for me as a 'contributor', I\n> do agree that the default 'maintainer' view of `pull` will need to be\n> retained for long term backward compatibility.\n\nOf course, but a maintainer never does `git pull` to merge a pull request,\nshe does `git pull github/john topic`, does she not?\n\nNobody was in favor of reversing the parents in the case of\n`git pull $where $what`, that would be the wrong thing to do.\n\nSo the maintainer view of `git pull` would remain fine.\n\n> What I have rarely seen in the discussion is explanation that is based\n> on workflow style, though the potential `update` command (1) may break\n> some of the deadlock about the direction of 'pull requests', and\n> possibly confusion regarding the location of the 'golden' publish repo.\n\nI think that's because most of the people that follow a workflow don't\nhave this problem.\n\nIt's only newcomers that don't follow any workflow that are hit by this.\nAnother name for this no-workflow is trunk-based development [1].\nEssentially everyone pulls and pushes to the same branch.\n\nPeople that use topic branches don't need `git update`, people who\nfollow trunk-based development do.\n\n> (1) there are a lot of 'update' commands floating about, esp on Git for\n> Windows. If there is a suitably named `update` command to do the `pull\n> --contributor` merge-ff swap then many of the issues could fade away.\n\nIndeed. And at least when I was maintaining my git-fc fork, people did\nenjoy my implementation of `git update`.\n\n[1] https://trunkbaseddevelopment.com/\n\n-- \nFelipe Contreras\n"},{"id":"431079","messageId":"60fb0a916c9cc_defb208eb@natae.notmuch","threadId":"56138","inReplyTo":"xmqqwnphowdx.fsf@gitster.g","subject":"Re: [PATCH] doc: pull: fix rebase=false documentation","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-23T18:29:37Z","receivedAt":"2021-07-23T18:29:42Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > So I feel compelled to say now that I do not think that changing the\n> > order of parents for \"git pull\" is the obviously correct thing to do.\n> > And likewise, in the one thread I do remember participating in, I\n> > expressed something similar:\n> >\n> > https://lore.kernel.org/git/20140502214817.GA10801@sigill.intra.peff.net/\n> \n> Thanks for the link. Many articles in the thread are repeating the\n> same opinion over and over (and later even descend into ad-hominem\n> attacks) and it is not worth anybody's time to read all of them, but\n> I found that there still were some gems.\n> \n> In an worldview where the first-parent chain is the trunk history,\n> merging in the upstream where you push back to into your working\n> repository where your new work is happening as the second parent\n> before pushing it back would obviously make the history that used to\n> be trunk to lose the first-parent-ness at that point. And if you\n> ask if I just said is correct, everybody would say it is. So there\n> is a concensus that the result of \"git pull upstream main\" becomes\n> a wrong shape for people in one workflow.\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\nWhy not? Everyone who saw a problem agreed it would.\n\nReversing the order of the parents creates a merge commit like so:\n\n Y---X-+\n \\\n B---A---M trunk\n\nMost git experts work with topic branches, and when you do that, you get\nthe same thing:\n\n topic\n |\n v\n Y---X-+\n \\\n B---A---M master\n\nIf you merge topic to master, the first parent of the merge commit is A.\n\nIf you do `git pull --reverse-parents` on a trunk-based workflow as\nabove, you would get exactly the same shape of the history.\n\nHow is it not the right shape?\n\n-- \nFelipe Contreras\n"},{"id":"431100","messageId":"xmqqo8asln78.fsf@gitster.g","threadId":"56138","inReplyTo":"60fb0a916c9cc_defb208eb@natae.notmuch","subject":"Re: [PATCH] doc: pull: fix rebase=false documentation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-23T21:44:43Z","receivedAt":"2021-07-23T21:44:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras 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?\n\nI gave detailed write-up in two discussion threads linked already in\nthis thread from 2013 and 2014; as I said, I do not think we want to\ndebate that as part of the discussion of this documentation fix.\n"},{"id":"431109","messageId":"60fb8f766963_1105920870@natae.notmuch","threadId":"56138","inReplyTo":"xmqqo8asln78.fsf@gitster.g","subject":"Re: [PATCH] doc: pull: fix rebase=false documentation","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-24T03:56:38Z","receivedAt":"2021-07-24T03:56:59Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras 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?\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\nSure, the discussion about the order of the parents is orthogonal to the\ndiscussion of this particular documentation fix, but my comment that the\norder of the parents is \"obviously wrong\" is correct. Even you said so\nyourself in the 2013/2014 threads (I would gladly provide the links if\nyou require them).\n\nI've spent several man-days re-reading the old threads (multiple times\neven, and not just the ones from 2013/1014), and I just spent several\nman-hours re-reading them yet again today.\n\nMy conclussion remains: the fact that the behavior is wrong is not\ndebatable (at least in some of the circumstances).\n\nI will provide a summary in a different thread soon.\n\n-- \nFelipe Contreras\n"}]}