Am 4/4/2012 0:09, schrieb Phil Hord: > On Tue, Apr 3, 2012 at 5:43 PM, Jon Seymour <jon.seymour@xxxxxxxxx> wrote: >> Suppose you have a merge of a A and B that produces M, which is then >> amended as M'. >> >> During rebase, you redo the merge A and B. If there are no conflicts, >> then compare M with M' to produce D. You now have enough information >> to reproduce the amended commit M' during a rebase (merge Ar and,Br >> then apply D). > > How does M' know it is an amended version of M? When you amended the > commit M you threw away this linkage. > > If you created M' as a new commit D instead, then I would agree that > you have enough information to do what you seek. In fact, I'm pretty > sure git does this already. 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? -- Hannes -- 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