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

Durham Goode durham at fb.com
Mon Apr 15 12:33:00 CDT 2013


On 4/12/13 3:15 PM, "Matt Mackall" <mpm at selenic.com> wrote:

>On Fri, 2013-04-12 at 17:07 +0000, Durham Goode wrote:
>> 
>> 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
>
>    -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?

With my proposal (1) would become a warning instead of an abort. Something
like:
"newer commits exist on another branch (use 'hg update -c' to go there)".
The rest of the chart should be unchanged since my change only affects the
case where 'rev == n'

>
>Is there bookmark-specific behavior that should be in this table?

Not at the moment.  My change (and the table as a whole, afaik) do not
have bookmark specific behavior.

>Should this table live in 'hg help update -v'?

The help -v already explains the rules (albeit in prose, not a table). If
anything I think we should make update have less rules so we have less
explaining to do (as Gilles proposed in their email).

>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".

I'm not sure what you mean here.  The whole purpose of my change is to
avoid an abort. We could add a 'warning:' in front of the message to give
it more emphasis I guess:
"warning: newer commits exist on another branch (use 'hg update -c' to go
there)"

But it's not actually a problem in a rebase workflow so I'm hesitant to
flag it as 'warning'.



More information about the Mercurial-devel mailing list