Johannes Sixt [off-list ref] 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