Re: [PATCH/RFC] rebase -p: do not redo the merge, but cherry-pick first-parent changes

[Johannes Sixt <j6t@kdbg.org>]

Am 22.05.2012 20:23, schrieb Junio C Hamano:
> 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.

Yes, in such a case we need some cleverness from the merge machinery in
cherry-pick: It has to recognize that some changes were applied on both
branches. This might generate new conflicts.

I'll have to see whether this is an issue in practice.

At any rate, if any difficulties with a particular merge commit can be
anticipated, it is always possible to replace the

  pick that-merge-commit

instruction by

  x git merge that-branch

(we could even generate these lines in the instruction sheet as a comment).

>> - 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?

Frankly, IMHO[*], rebase -p that is based on git-cherry-pick is so much
better that I don't want to think about which workarounds would be
needed to make it work better with git-merge :-)

[*] It is still only an opinion. I haven't gotten around to use the
updated rebase -p in the field. Another reason that it's still RFC.

Thanks,
-- Hannes