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