From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 22 May 2012 18:23:09 GMT
Subject: Re: [PATCH/RFC] rebase -p: do not redo the merge, but cherry-pick first-parent changes
Message-ID: <7vobpg3wj6.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4FBAA33D.1080703@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

> When rebase -p had to replay a merge commit, it used to redo the merge.
> But this has drawbacks:
>
> - When the merge was evil, i.e., contained changes that are in neither of
>   the parents, that change was not preserved.

This is a desiable property, and not necessarily limited to "evil" merges
but also applies to everyday conflict resolutions.  Replaying the change
between the merge and its first parent is a way to achieve it, but I think
it also has downsides.  If you are replaying a merge to an updated history
that already contains a part of what is merged, some part of the
difference between the original merge and its first parent already exists
in the commit that the will become the first parent of the replayed merge.

> - The 'git merge' invocation passed the commit message of the old merge
>   commit, but it still obeyed the merge.log option. If it was set, the log
>   ended up twice in the commit message.

This should be fixed independent of this patch, no?  Is it a matter of
just passing --no-log or something, or is there anything more elaborate
necessary?