Conflicts created when switching with uncommitted changes confusing

[Mary Gardiner]

Scenario:

I have two related branches, 1 and 2. Since 1 and 2's histories parted, I have added file X to branch 1 and committed some version(s) of it but not merged it into branch 2. I am working in ~/working-copy, which is a lightweight checkout of branch 1.

1. Edit file X.
2. Without committing the new changes to file X, attempt to "bzr switch" to branch 2.

Result:
File X is deleted from ~/working-copy and a "contents conflict" is reported. The version of X committed to branch 1 is present in the working copy as X.BASE and the uncommitted version at the time of switching is X.THIS.

Problems with this:
1. A "contents conflict" is reported in a file X which turns out, on inspection, not to actually be present in the working tree. This is both immediately alarming ("oh crap, X got DELETED?") and also simply time wasting once that's sorted out.
2. The .BASE and .THIS terminology is really confusing in this case. .THIS is not "this" anything (this branch, this working copy), it's from the working copy as it was just prior to the switch.
3. bzr wants to add X.THIS to the repository (it shows up in "bzr st" as an added but not committed file), this is probably related to other bugs I've reported, but in any case I can't see any case in which this is ever going to be the correct solution to the conflict.

I am not sure what a correct solution would look like. Here's some possibilities:
1. it would be really nice if I could immediately revert my working tree to the way it was before "bzr switch" rather than resolve these kinds of conflicts one by one. Having to understand and back myself out of this mess seems unfair punishment for what was a minorly silly thing for me to do.
2. X.BASE and X.THIS could have slightly more helpful names.
3. "Contents conflict" is a misleading description in this case, I'd really like a fuller description of what happened. "File X not present in [branch 2], uncommitted changes to file X against [branch 1] moved to X.UNCOMMITTED."

[Dimitrios Apostolou (jimis)]

I've been bitten by this as well, so here is what behaviour of "bzr switch" I think would be better. In order of preference:

* keep the uncommitted changes on the previous branch, when I do "bzr switch" I don't really mean merge, I should do a separate "bzr merge --uncommitted branch1" for that. That means that each branch should have a special staging area to keep its uncommited changes?

* If it's too much to change default behaviour, provide it as an option, for example "bzr switch --nomerge".

* Warn that conflicts are detected, ask if you really want to switch so you can go back and shelve.

[Aaron Bentley (abentley)]

Dimitrios, I've implemented "bzr switch --store", which is basically what you asked for as "bzr switch --nomerge". It's on trunk now, and will be in bzr 2.6 beta 3.

[Aaron Bentley (abentley)]

Merge --uncommitted is supported by the bzr-pipeline plugin, and I may add it to trunk as well.

[Dimitrios Apostolou (jimis)]

Thanks Aaron, I prefer to have vanilla functionality (no plugins) so it's cool to have the functionality there. I'll test --store from trunk and report back. Wouldn't it be nice to also have a warning for when switching with conflicts, something like "Conflicts detected, are you sure you want to switch branch? y/n".