Hello, I was wondering if there are any plans to enhance the rebase functionality to match something like [1], specifically to handle rebasing merge commits. My understanding of the current rebase implementation is that it dumps all the changes as a patch, moves HEAD, and applies the patch. This works great for regular commits, but if one of the new commits was a merge, rebase seems to "flatten" the merge. Because the patch dump doesn't include any information about the merged commit's existing hashes/parents, when the patch is applied, each merged commit gets reapplied as a new commit, with a new hash, and no DAG link back to where the original pre-rebase merge came from. We've had this happen on topic branches when devs merged in a new stable release that contains ~100 commits, but had their branch's remote head move on them, so they pull --rebase as usual, but end up with all ~100 commits from the release essentially cherry-picked into their topic branch. So now we have the disclaimer of "usually pull --rebase...unless you've done a merge, then do a pull --merge". [1] seems to solve this with some fairly complex cherry-picking and ancestry manipulation that, admittedly, I don't quite understand, but it seems like it might be able to bring along a merge's multiple parents information throughout the rebase and maintain the merge as a single, non-flattened merge commit. Thanks, Stephen 1: http://www.selenic.com/mercurial/wiki/index.cgi/RebasePlan -- 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
