'bzr switch' gives no indication that working copy has changes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Parth Malwankar wrote:
> Public bug reported:
>
> I recently faced this issue with using bzr switch with lightweight checkout.
> I was working in a lightweight checkout and had some un-checkedin changes. After working on something else for a day I had forgotten about this. To work on another branch I just did a 'bzr switch PATH' and this worked ok and I went ahead and added another set of changes. On doing a diff I realized I had my old changes which were meant to be in another branch as well as new changes. I ended up using 'bzr shelve' interactively to separate my old changes from the new.
>
> IMO at a minimum switch should show a warning so that the user can use
> shelve immediately or switch back and commit changes. Or maybe a --force
> option can be supported.
>
> Below is roughly what I did.

Switching with uncommitted changes is one of the primary use cases for
switch (oh, here is a simple bug fix, let me put this in a separate
bugfix branch).

That said, notifying the user that there are uncommitted changes is
reasonable.

Also, there is a fairly serious failure mode. Where you have uncommitted
changes in a newly added file. When you go to switch that file will end
up conflicted (changes to a file that don't exist), but you cannot
trivially switch back to the previous branch (because then it will
conflict again, because you have all these conflict markers, etc.)
Separate bug, though.

A warning would be ok, --force would not. Though a user could presumably
configure a setting if they never use the "let me put this in another
branch" case.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkv/2JkACgkQJdeBCYSNAANHlACgki9WwivEMZxXtP1wqij7VWuf
agcAn1nk9k2yYbWuuvh5900w5rlWHnMk
=jHdT
-----END PGP SIGNATURE-----

--strict/--no-strict seem close than --force, yet, I don't think that will work well for the use case mentioned by John.

So there is a high risk that defining this option becomes unproductive...
Or may be I can't see the proper way to set it... per branch ?

May be we miss some other feature here like:
- let me commit these changes into another branch while keeping my current branch and the other
  uncommitted changes,
- switch to this other branch, keeping the changes I want to commit while shelving the other ones.

I've been bitten by this, could not go back because of conflicts, really messed up my workflow.
I'd certainly welcome a warning, like "You have uncommitted changes, merge them to new branch? y/n".

But instinctively I still expect the uncommitted changes to stay at their source branch, and if I want them I should do "bzr merge --uncommitted".