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

Thomas Rast [off-list ref] writes:

Junio C Hamano [off-list ref] writes:

quoted

worley@alum.mit.edu (Dale R. Worley) writes:

quoted

(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.