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

[Durham Goode]

On 4/10/13 5:17 PM, "Matt Mackall" <mpm at selenic.com> wrote:

>On Wed, 2013-04-10 at 20:24 +0000, Durham Goode wrote:
>> On 4/10/13 1:22 PM, "Augie Fackler" <raf at durin42.com> wrote:
>> 
>> >On Wed, Apr 10, 2013 at 12:55:39PM -0700, Durham Goode wrote:
>> >>
>> >> o  3
>> >> |
>> >> | o  2
>> >> | |
>> >> | @  1
>> >> |/
>> >> |
>> >> o  0
>> >>
>> >> 'hg update' will now put you on commit 2.  If you were already on
>> >>commit 2,
>> >> it would be a no-op.  If you were on commit 0, it would put you on 3.
>> >
>> >Where would it put you before this change?
>> 
>> It would give you an error "abort: crosses branches" because it tried to
>> go to 3.
>
>So.. user on 2 will now be given the false impression they were
>up-to-date? Prepare for a flood of "where did my incoming changes go?"
>or even more clueless bug reports.
>
>It's underspecified here whether you're talking about this being
>bookmark-specific behavior, and it seems from the patch that it's not.
>It's definitely not the right answer if there are no bookmarks involved.

To better specify: this change is not bookmark specific. It always applies.

If a user sees "abort: crosses branches" they're going to have to
investigate anyway to learn why it failed.  That same investigation holds
true with my change if hg update reports nothing changed. I think the new
behavior is more globally useful and intuitive (for anonymous branch
workflows, named branch flows, and bookmark flows).

Would it help to output a message when it's not going to the absolute tip?
 I'd hesitate to print anything named-branch specific since it would just
confuse people using bookmark workflows.