Re: "git rebase" loses the additional changes in "evil" merges

From: Philip Oakley <philipoakley@iee.org>
Date: Mar 5, 2013, 22:47 UTC
Message-ID: <D9E55432793A444F941789A493F97B1C@PhilipOakley>
In-Reply-To: <7vy5e1sf6b.fsf@alter.siamese.dyndns.org>

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Tuesday, March 05, 2013 9:35 PM

Show 13 quoted lines

> Dale Worley <worley@c-66-31-108-177.hsd1.ma.comcast.net> writes:
>
>>> From: Junio C Hamano <gitster@pobox.com>
>>>
>>> I think this is to be expected for "git rebase", as it does not even
>>> look at merges.  It is a way to find non-merge commits that haven't
>>> been applied yet, and apply them to the upstream to create a new
>>> linear history.
>>
>> I disagree. "git rebase" is not characterized as ...
>
> The intention has always been "I have these patches, some were
> applied upstream already, now what do I have left?".

Given that many folk appear to trip up with their rebase mindset, does this suggest that a few tweaks to the manual may be in order to stop such misunderstandings?

Perhaps:
    git-rebase - Forward-port local commits, not in upstream,
     to the updated upstream head

and to avoid "hidden" asides, add a few more paragraph breaks into the description texts, and perhaps bring the "Note that any commits in HEAD which introduce the same textual changes as a commit in HEAD..<upstream> are omitted" sentence nearer the start.

That is, don't let folks get a too simplistic view of rebase, missing its hidden powers.

>
> You do realize that you are disagreeing with somebody who designed
> the original "git rebase" (before the --preserve-merges was added),
> do you?

However the broader userbase brings with it a better class of fool ;-)