Code review comment for lp:~craighewetson-deactivatedaccount/bzr/update_with_local_commit

> Whats the motivation for this? [what does bzr do wrong at the moment].

The following steps will illustrate the problem:
Modify fileA.
Commit --local fileA.
Modify fileA (without committing)
Then do an update.

Result:
Bazaar creates non intuitive conflicts for work that only he (the user) modified.

Bazaar doesn't do anything wrong, but it produces an output that the user will not make sense of. The user would have to rename fileA.moved.THIS to fileA and then do a bzr resolve fileA.

Its worth doing the above steps just to test it and see what I mean.

Now imagine: I had to somehow explain to my colleagues (being the resident Bazaar promoter) that bzr was doing the correct thing after it created conflicts for many critical changes that only my colleague made.

>I think its important to be able to update with local changes - its the workflow that update is intended for.
It does allow you to do this but with one limitation, first locally commit your changes to proceed with update. By doing this one can eliminate the negative effect of the above problem.

There is one further improvement that can be made:
On doing an update I could check to see if any of the modified files (eg: fileA) is within the local commits. It could then tell the user that the following files: FileA... needs to be locally committed before proceeding etc.