Thomas Rast <> writes:

> Junio C Hamano <> writes:
>> (Dale R. Worley) writes:
>>> (git version
>>> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to