bzr update merges changes even with uncommitted changes

[Marius Kruger]

2008/12/11 John Arbash Meinel <john at arbash-meinel.com>

> 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?
>
> 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.


My situation is where I had _local_ commits before I bound the branch.
To make it worse, I wasn't ready to commit either.
Maybe it would be reasonable to refuse to "convert local commit to pending
merges"
if the tree isn't clean.


> Perhaps you want to work in 2 branches?

yes, but that is so much overhead for small new projects.


> So that you never need to update


I don't know what I was thinking but I actually ran update to see if it will
push my local commits up.. ..don't laugh.


>
> your feature branch, and then merge it into your "trunk" branch as a
> separate action.
>


thanks
marius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20081211/d4453cbf/attachment.htm