support assisting the decision about where an uncommitted change should be committed

[Forest Bond]

See also bug #227339

When switching threads, conflicts between uncommitted changes and the new base can arise.

These WT conflicts are sufficiently disruptive to warrant a --force requirement, and can result in a mildly destructive situation, as valuable changes in the WT mingle with the conflict and must be manually resolved before the user can even switch back to the thread he came from.

Example:
  Thread A is an base-level thread, thread B is work built on top of that.
  User is in thread A after cleaning up some changes, and they forgot to switch to their other thread.
  They make some changes in the same location as thread B, not realizing that the text is not their current tip.
  They realize that they aren't using their latest, and use "bzr switch B".
  At this point it tries to roll forward, and causes conflicts because of overlapping changes, even though there weren't any changes in thread A that needed to be merged into thread B.

The last point is what makes this different from bug #227339

[John A Meinel (jameinel)]

Another example which is somewhat less "trivial".

A user has been struck with inspiration and gone on a bug fixing spree, and now needs a way to separate out their changes into a more logical set of patches.
At this point they have a fairly involved set of changes in the WT which are being split up while switching between threads.
While in the process of deciding what changes go where, they sometimes do a test switch, to see if this change would fit best in that thread.
If that ends up in a conflict,
  A) they probably don't want it in that thread after all, and
  B) they can't switch to another thread because they now have conflicts that have to be resolved.

having a way to avoid the switch if it would conflict allows them to poke around a bit to find where things fit best, without going through a time-consuming conflict resolution process before they get to jump again.

[Forest Bond (forest-bond)]

For me, this situation typically arises if the user is carrying several changes around with him in the WT as he switches threads. Eventually, a WT change may conflict with a thread that the user switched to, even if the user has no intention to commit that particular change on that particular thread. However, now, in order to restore mobility to his loom, the user must resolve the conflict.

For instance, suppose I have three threads:

C
B
A

Now, suppose I make some changes while my current thread is B, but then I realize that some of those changes should be committed in A, some in B, and some in C. I will probably `bzr commit' the changes that belong in B, and then do `bzr down-thread' to commit the changes I want in A. But what if the changes destined for C conflict with A? If I had known ahead of time that this was the case, I might switch to C to commit those changes first, or I might shelve the changes for C, commit changes in A, switch to C, and then unshelve the changes for C.

The primary distinction between this issue and that covered by bug #227339 is that, here, the conflict is between the WT and previously committed revisions in the thread being switched to, whereas #227339 deals with pending merges as a result of moving up the loom after committing to a lower thread.

[Robert Collins (lifeless)]

So, there are several things to tease apart here:
 - how do you commit changes to a different branch/thread
 - what is the primary use for switch
 - whats the best default.

I'll support a --require-clean mode on switch or something, to say 'dont switch if there are conflicts', but defaulting to that seems really weird - pull itself can conflict when a directory is deleted and there are pyc files left behind; forcing switch to break when that happens would just annoy me :)