[PATCH RFC] update: default update should move as far forward as possible (issue3883)

[Gilles Moris]

On Saturday 13 April 2013 12:15:49 am Matt Mackall wrote:
> On Fri, 2013-04-12 at 17:07 +0000, Durham Goode wrote:
> > On 4/11/13 1:15 PM, "Matt Mackall" <mpm at selenic.com> wrote:
> > >First, I'm happy to agree that the old message sucks. But it does tell
> > >the user that a) they have an issue and b) it's somehow related to
> > >branching.
> > >
> > >But "hg update" doing this:
> > >
> > > $ hg update
> > > 0 files updated, 0 files merged, 0 files removed, 0 files unresolved
> > >
> > >says "everything's fine" to all but the most clueful, attentive users.
> >
> > What about something like:
> >
> > $ hg update
> > newer commits exist on a different branch - merge or rebase to reach them
> > 0 files updated, 0 files merged, 0 files removed, 0 files unresolved
> >
> > It's more explicit than the current message, it's relatively applicable
> > to both branch and bookmark flows, and hg update is still useful for
> > moving to descendants.
>
> That looks promising. However, I think we need to look at the big
> picture here. Update has -lots- of different cases and we need to make
> sure that our changes are coherent.
>
> We've got this table hiding in merge.py:update:
>
>     -c  -C  dirty  rev  |  linear   same  cross
>      n   n    n     n   |    ok     (1)     x
>      n   n    n     y   |    ok     ok     ok
>      n   n    y     *   |   merge   (2)    (2)
>      n   y    *     *   |    ---  discard  ---
>      y   n    y     *   |    ---    (3)    ---
>      y   n    n     *   |    ---    ok     ---
>      y   y    *     *   |    ---    (4)    ---
>
>     x = can't happen
>     * = don't-care
>     1 = abort: crosses branches (use 'hg merge' or 'hg update -c')
>     2 = abort: crosses branches (use 'hg merge' to merge or
>                  use 'hg update -C' to discard changes)
>     3 = abort: uncommitted local changes
>     4 = incompatible options (checked in commands.py)
>
> Is this table correct and complete? The first line, 'same' column seems
> to say "hg update with no args and clean working directory that wants to
> go to a head that's on the same branch but isn't a linear descendant..
> gets error message (1)". Do we not get that hint?
>
> Is there bookmark-specific behavior that should be in this table?
>
> Should this table live in 'hg help update -v'?
>
> Also, I kindof like abort+hint. Abort says "pay attention, n00b, I
> didn't do what you told me to", while hint says "try this".
>
> Lastly, mentioning non-core commands like "rebase" in the output of core
> commands is problematic.

The problem with this patch is that "hg up -c" is still forcing the latest rev 
in the current branch in commands.py, so that it will need to be fixed as 
well.

This is symptomatic of few design problems in this area:
- The logic is split between commands.update and merge.update. This table in 
merge.py explains behavior depending on flags parsed in commands.py. We 
cannot even directly sense anymore what was the content of those flags.
- This table was originally for developers, due to the complexity of the 
different cases. But it probably ought to go in the help.
- When I was doing training to my team, explaining all those different cases 
was a real pain. I would like it to be simplified such that:
  * there is no distinction between named branch and anonymous branches, and 
here this patch would help as the first line would be only linear by 
construction (provided some warnings are added):
    -c  -C  dirty  rev  |  linear   same  cross
     n   n    n     n   |    ok      x      x
  * there is no distinction between linear and non-linear, so that we always 
merge local changes by default (provided there are some undo mechanism in 
place), so that the 3rd line looks like:
    -c  -C  dirty  rev  |  linear   same  cross
     n   n    y     *   |   merge   merge merge
  * --check promises that it only checks for local changes, but it does more 
than that by subtly changing the target to the latest rev of the branch. It 
shall not do that.

With all that, the right side of the table just contains 1 column, line 1 and 
6 ('hg up' and 'hg up -c') behave the same. However, this might be too much 
and violates the backward compatibility / safety principles.

Regards.
Gilles.