how to revert update operation

John Arbash Meinel john at
Tue Jul 18 16:19:31 BST 2006

Hash: SHA1

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>>> Aaron: can you comment? It seems like we are doing to 'merge' actions.
>>> I'm wondering if the working tree is ever in an invalid state, or if we
>>> are doing everything into limbo.
> I didn't write WorkingTree.update, and it kinda scares me.
> I'm not convinced that the rationale given for doing two merges is
> correct, but I'll have to think about it some more.
> It does do two merges.  So I guess you'd be in an unexpected state if
> you aborted between the two merges, but it wouldn't be an /invalid/
> state, just not a correct one.
> Aaron

Well the premise that I believe Robert was following when he wrote it,
was that if you are a checkout, you are declaring that the other branch
is the 'master', and you really want to follow it. (After all, you could
always just unbind if you wanted to go another way).

So 'bzr update' actually updates you to the 'master' branch revision,
and then merges your old working tree into it, and sets the pending merges.

I *think* we forbid update if there are local commits, and some
uncommitted changes. If it doesn't, it probably should.

Is there an easy way with the merge and TreeTransform code to say "take
this tree, merge it into this other tree, and then replace the original
tree with the merged result"?

I think the code is doing 'merge this into other' which creates a state,
and then does 'merge state into this' to update the working tree.

The difficulty is that you don't want to just merge other into this (you
have bzr merge for that). You want to replace this with that, and merge
the original this.


Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the bazaar mailing list