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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 21, 2021 at 08:24:25PM -0500, Felipe Contreras wrote:

> I'm not trashing the current behavior, I'm explaining what the consensus
> is. I spent several man-days re-reading old threads, and this is the
> consensus of what should happen:
> 
>   1. git pull              # merge HEAD into upstream
>   2. git pull origin topic # merge topic into HEAD
> 
> Of the people that expressed an opinion, 100% of them stated that what
> `git pull` does in the first case today is not desirable.

I did not participate in the threads you linked earlier, so I am
probably not in that 100%. But you did use my name below:

> Yes, you are correct that if *everyone* followed the topic branch
> workflow, everything would work correctly, but that's not what happens
> in reality, in reality people do all kinds of workflows, and wrong
> merges are pervasive.
> 
> Everyone--including Linus, Jeff, and you--agree that there's two
> different ways of using `git pull`: integrator versus developer.
> 
> When a user is doing `git pull` to synchronize changes to push to the
> same branch, that's a centralized two-way workflow, so he is acting both
> as an integrator and as a developer, and it's in that particular case
> that the order of the parents should be reversed. Everyone agrees on
> that.
> 
> When the user the opposite explicitely: `git pull origin master`
> Linus calls it a "back-merge" [1], and in that case the order of the
> parents should not be reversed.

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/

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux