How to cope with bazaar uncommits

Hit the following situtation a couple of times today:

1. Myself and another dev both have bazaar local checkouts of a repository.
2. I make some changes.
3. The other dev makes and commits some changes.
4. I update.
5. The other dev realises their previous changes were broken and uncommits them.
6. I update.

Now the o开发者_开发知识库ther dev's uncommitted changes appear as a pending merge in my local checkout, and I can't find a way to separate them from my changes and remove them from my 'local' tree.

Every time this has happened I've had to manually work out which changes are mine and which are not, save my changes, revert, and then re-apply my changes.

I've tried doing a "cherrypicking" reverse merge on my checkout between -r -1..-2, and between -r 0..-1, but neither helped. (0..-1 said "nothing to do", although I might not have done it properly. -1..-2 was the wrong set of changes and thus made things worse.)

How can I fix this situation when it happens (other than going over and smacking the other dev upside the head)?

It is recommended that you don't uncommit in branches that are published somehow, thus avoiding this issue.

Well once you have updated (step 4), the other guy's changes will be merged with yours permanently. Since your changes were uncommitted, they aren't stored anywhere. Therefore, once step 6 has happened, I don't really see a way of automatically separating out your changes from his.

So let's say you manually remove all of his changes so you're just left with yours. You still have this pending merge to deal with. You can fix that by typing

$ bzr revert --forget-merges

That will not change your working tree; it will only remove the pending merge from your "bzr st" so that when you commit it will not look like a merge. This should save you from having to save your changes, revert and re-apply.

To avoid this happening again, you could run bzr update only immediately before you commit. Once merged, to a bzr commit right away, and your changes are locked in. Now he won't be able to uncommit without first updating and seeing your changes, and now it's probably too late for him to do that. If he really wants to go ahead with his uncommit, he's the one that has to deal with the mess, not you.

One final thing you can do -- if you really don't want to deal with it and you don't care too much about having a nice version history. After step 6, just commit. Maybe explain in your log that the other dev uncommitted this change but too late.

This is where the pending merge comes in. If you commit, the uncommitted revision will go back into the repository, as a branch, just as if the other dev had send those changes to you in an email and you merged them. It will look like this:

------------------------------------------------------------
revno: 34 [merge]
committer: You
branch nick: trunk
timestamp: Fri 2010-11-26 15:57:27 +1100
message:
  Made my changes to the file.
  Note, other guy did some of these changes and uncommitted, but
  I already merged.
    ------------------------------------------------------------
    revno: 33.1.1
    committer: Other Guy
    branch nick: trunk
    timestamp: Fri 2010-11-26 15:39:39 +1100
    message:
      Made some changes to the file.
------------------------------------------------------------

When he runs update again, he'll have his old changes thrown back at him, and probably get a conflict. He'll have to clean it up, then commit his fixes (whatever reason he had to uncommit in the first place). This is probably just as effective as a smack upside the head, and works over a network :)

It looks like bzr pull --overwrite :bound is what you're after.