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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 23, 2021, 15:58 UTC
Message-ID: <xmqqwnphowdx.fsf@gitster.g>
In-Reply-To: <YPpwIazVxL4GoLbC@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 6 quoted lines

> 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.
> 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/

Thanks for the link. Many articles in the thread are repeating the same opinion over and over (and later even descend into ad-hominem attacks) and it is not worth anybody's time to read all of them, but I found that there still were some gems.

In an worldview where the first-parent chain is the trunk history, merging in the upstream where you push back to into your working repository where your new work is happening as the second parent before pushing it back would obviously make the history that used to be trunk to lose the first-parent-ness at that point. And if you ask if I just said is correct, everybody would say it is. So there is a concensus that the result of "git pull upstream main" becomes a wrong shape for people in one workflow.

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.