[PATCH RFC] update: add an option to allow to merge local changes when crossing branches

[Pierre-Yves David]

On Sun, Mar 17, 2013 at 10:36:22PM +0100, Gilles Moris wrote:
> On Thursday 14 March 2013 12:15:54 pm Laurens Holst wrote:
> > Op 14-03-13 12:01, Pierre-Yves David schreef:
> > > I forget to finish what I'm doing before moving to something else:
> > > - I forget to commit my merge after conflict resolution
> >
> > Updating while there is an uncommitted merge is I think a separate check
> > that should remain in place, even when updating to an ancestor.
> >
> > > - I forget to amend my change in the relevant commit before moving to
> > > something else.
> > >
> > > And I'm usually reminded by mercurial telling me:
> > > - uncommited merge
> > > - refuse to update with uncommited changes
> > > So I can avoid the error early.
> >
> > But you *can* update with uncommitted changes. Just not to another
> > topological branch. So if that’s the rationale, then you can’t
> > consistently apply it unless you use the --check flag. And if you use
> > that flag, then you won’t be affected by the change in default behaviour.
> >
> > So I don’t think that is a good, or at least consistent argument to
> > prevent updating across branches by default. It would be an argument for
> > making --check default, however I think nobody wants that because it
> > makes the tool more obnoxious and less convenient to use.
> >
> > Similarly, the tool complaining just about cross branch updates is
> > obnoxious and inconvenient, and if we have a means to roll back an
> > update with merge conflict, this particular restriction by itself does
> > not seem to serve any purpose in preventing the user from shooting
> > himself in the foot.
> >
> > ~Laurens
> 
> So it seems that this leaves us with 3 options:
> 1/ maximal safety: make --check the default to avoid any update with 
> uncommitted files.
> But then add a --merge option that merges local changes both linearly and 
> across branches.

Would make sense, but will break backward compatibility

> 2/ Allow merging local changes by default both linearly and across branches.
> But possibly:

The odds of doing a cross branch update by mistake is much higher than
the odds of mistake for linear update.

>   a/ provide a mechanism, like a --revert option to cancel the last update

--revert is very confusing. an "hg undo" our "hg update --undo" that
pbring you back in the state prior update would make sense.

>   b/ warn the user when local changes have been merged/rebased

We already do that a bit. We could a bit clearer.

> 
> 3/ still prevent bare update across branches but provide an option to allow it 
> (this patch).
> 
> I do not like solution 3/. I have made some training to my team and it has 
> always been a pain to explain all the different cases where we can or not 
> update to another branch, and which option to use. As Mercurial developers, 
> we even need a table to understand them [1].

For my part I can see prefectly valid reason to be stricter in cross
branch update. They are much more likely to move you to an unrelated
part of the code.

However this must be possible to do this update one way or another.

> So it would be preferable to go to 1/ or 2/ to simplify this area, and I would 
> prefer 2/ if 2a and 2b are fulfilled. Can we reach a concensus on that?

1 and 2 two seems non-backward compatible :-( I'm not sure which one of the
two I would prefer otherwise. Maybe (1) for safety reason (in doubt, you
user is a drunk otter)

-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130320/eabee4ce/attachment.pgp>