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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 4, 2013, 21:41 UTC
Message-ID: <7vppzex2pq.fsf@alter.siamese.dyndns.org>
In-Reply-To: <87sj4aoo3s.fsf@pctrast.inf.ethz.ch>

Thomas Rast <trast@student.ethz.ch> writes:

Show 20 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> worley@alum.mit.edu (Dale R. Worley) writes:
>>
>>> (git version 1.7.7.6)
>>>
>>> I've been learning how to use Git.  While exploring "git rebase", I've
>>> discovered that if the branch being rebased contains an "evil" merge,
>>> that is, a merge which contains changes that are in addition to the
>>> changes in any of the parent commits, the rebase operation will
>>> silenty lose those additional changes.
>>
>> 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 can see the problem with --preserve-merges though.  It will actually
> just *redo* the merge; the name is wrong in the sense that it undertakes
> nothing to preserve whatever evilness was in it.

With or without evil, preserve-merges have other issues to make me not to trust it. Which side branches to take literally (i.e. just merge again) vs which side branches to also rebase (i.e. rebuild the history and then merge).

It was suggested to make it apply the first-parent diff and record the result, I think. If that were an acceptable approach (I didn't think about it through myself, though), that would automatically cover the evil-merge case as well.