bzr update merges changes even with uncommitted changes

John Arbash Meinel john at
Thu Dec 11 15:24:40 GMT 2008

Hash: SHA1

Marius Kruger wrote:
> hi,
> This is the the third time today I've seen `bzr update` do a merge where
> there
> has been not-yet-committed changes in my working tree (different times,
> different places!).
> This is bad, it messes up my working tree
> so that I don't know what is new changes and what is part of the pending
> merges.
> AFAIK, `bzr merge` refuses to run if you have uncommitted changes (or
> you --force it).
> I don't know if I or others have complained about it in the past.
> Can I/we change it to work like merge?
> regards
> marius
> --
> 1ce ok, 2ce ok, 3rd time rant!

That sort of breaks the whole point of "update".

You can't commit if your working tree is out of date, so you "update"
which brings in the remote changes into your local tree (via a merge),
so that you can then commit.

I could see having a "bzr update --stop-if-changed", which would give
you a chance to shelve or something else.

But really the whole *point* of update is to be able to merge in
already-committed changes along side your uncommitted changes, so that
you can finally commit them.

Perhaps you want to work in 2 branches? So that you never need to update
your feature branch, and then merge it into your "trunk" branch as a
separate action.


Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla -


More information about the bazaar mailing list