Comment 1 for bug 152008

At the moment, this isn't representable in our data model. The problem is that history is immutable, and you have a revision which says it includes everything from the other branch.
In our current model, if "X" is in your history, than all ancestors of "X" are also included. This is vastly simplifies the work you have to do to find common ancestors between two branches. (Without it, you always have to search all of history to see if one of the ancestors was selectively not merged).

To further clarify, you aren't trying to unmerge the last commit, but instead one several commits ago, correct? The only way to do that (at the moment) is to uncommit back to just before the merge, and then recreate all the other commits (skipping the merge one). Which is something Jelmer's "rebase" plugin should be able to help with.

Or you could do something like:

cd existing
bzr branch -r -10 ../before_merge
cd ../before_merge
bzr merge -r -10..-1 ../existing # This "skips over" the merge revision, and cherry picks the rest
bzr commit -m "Cherry pick the changes since the merge"
cd ../existing
bzr pull --overwrite ../before_merge

This will lose the identities of the individual commits since the point you want to extract. Which is where "rebase" would actually try to merge and commit them one by one. So they would have new identities, but the textual changes and commit messages should be preserved.

You are actually looking for more of a "cherry-unpick" function (than a "cherry-pick"), and is certainly a use case we need to think carefully about.