Nico Williams <nico@xxxxxxxxxxxxxxxx> writes: > On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >> Sergei Organov wrote: >> >>> Is there any scenario at all where pull --rebase=true wins over >>> preserve? >> >> Basically always in my book. ;-) >> >> When people turn on 'pull --rebase', they are asking for a clean, >> simplified history where their changes are small discrete patches in a >> clump on top of upstream. > > +1. Words to develop by. > > There are exceptions. E.g., when you pull commits from multiple > [forked] upstreams, then you can't keep your local commits on top. > > That exception aside, keeping all local commits "on top" by always > rebasing them onto the upstream is extremely useful: a) in simplifying > conflict resolution, b) making it easy to identify as-yet-unintegrated > local commits, c) making it easy to contribute local commits. But 'pull --rebase=preserve' does rebase local commits onto the upstream, and result is exactly the same as 'pull --rebase=true', unless you have some of your own merges to be rebased. That's where the difference between these two options appears. It's --rebase=false that performs merges rather than rebase. Overall, I still can't see where '--rebase=true' wins over '--rebase=preserve'. -- Sergey. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html