rebasing merges

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