Re: Amending merge commits?

From: Sergei Organov <osv@javad.com>
Date: Jul 29, 2014, 09:58 UTC
Message-ID: <87r4147agk.fsf@osv.gnss.ru>
In-Reply-To: <CAK3OfOjr6ej5VdGU=bLmtag9cca1=ogLxVakCFTMG7b-A2uBiA@mail.gmail.com>

Nico Williams <nico@cryptonector.com> writes:

Show 21 quoted lines

> On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder <jrnieder@gmail.com> 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.