Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > 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@xxxxxxxxxxxxxxxxxxxxx/ > > 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. 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? -- Felipe Contreras
