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

From: Johannes Sixt <j6t@kdbg.org>
Date: May 22, 2012, 19:30 UTC
Message-ID: <4FBBE949.8060305@kdbg.org>
In-Reply-To: <7vobpg3wj6.fsf@alter.siamese.dyndns.org>

Am 22.05.2012 20:23, schrieb Junio C Hamano:

Show 15 quoted lines

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

Show 7 quoted lines

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