Junio C Hamano <gitster@xxxxxxxxx> writes:
> Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes:
>
>> IMO, it is a sub-optimal implementation of rebase -p that it attempts to
>> redo the merge. A better strategy is to just replay the changes between
>> the first parent and the merge commit, and then generate a new merge commit:
>>
>> git diff-tree -p M^ M | git apply --index &&
>> git rev-parse M^2 > .git/MERGE_HEAD &&
>> git commit -c M
>>
>> This would side-step all the issues discussed here, no?
>
> Or cherry-pick the change made by the merge to its first parent, i.e.
>
> git cherry-pick -m 1 M
Err, that was a confusing unfinished message. I meant the step to replace
the part that uses pipe to "git apply", more like
git rev-parse M^2 >.git/MERGE_HEAD &&
git cherry-pick --no-commit -m 1 M &&
git commit -c M
The primary difference is that, because "apply -3" is not implemented yet,
this will help when the base has drifted too much from the corresponding
blob recorded in M^.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html