Subject: Re: Amending merge commits?

From: Sergei Organov <[email-masked]>
Date: Tue, 29 Jul 2014 13:58:35 +0400

Nico Williams <[email-masked]> writes:

> On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder <[email-masked]> 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.