Changing the UI of checkout

Marius Kruger amanic at gmail.com
Tue Apr 21 20:06:35 BST 2009


2009/4/20 Stephen J. Turnbull <stephen at xemacs.org>:
...
> For example, there is no good reason for bzr commit to ever fail in a
> checkout, unless new commits in upstream are in genuine conflict with
> the working tree.  To address the not up-to-date case, it should
> automatically do an update before committing.[1]  To address the merge
> conflict case, bzr commit should automatically shelve the uncommitted
> changes before updating, then unshelve before pushing, and in the case
> of merge conflicts should preserve the local changes in case later
> analysis shows that the merge needs to be unwound, but the feature
> you're checking in now should be preserved.

This makes a lot of sense to me, and I think it would be great.
At some point I tried to figure out how to detect the case where we
have local and remote commits and local changes, so that we can refuse
to do that. But since we have built in shelve capabilities,
that makes more sense.
I got lost in the code though and didn't have time to look at it again.


-- 
<| regards
U| Marius
H| <><
Z| http://amanica.blogspot.com/



More information about the bazaar mailing list