[PATCH 1 of 2] update: warn about other topological heads on bare update

[Sean Farley]

Pierre-Yves David <pierre-yves.david at ens-lyon.org> writes:

> On 02/03/2016 05:43 PM, Pierre-Yves David wrote:
>> # HG changeset patch
>> # User Pierre-Yves David <pierre-yves.david at fb.com>
>> # Date 1454424542 0
>> #      Tue Feb 02 14:49:02 2016 +0000
>> # Node ID d61062a8e69c5586171a9207994c13dfc69ea975
>> # Parent  8e79ad2da8a69735488402fd018dd82bc1eb9309
>> # EXP-Topic destination
>> # Available At http://hg.netv6.net/marmoute-wip/mercurial/
>> #              hg pull http://hg.netv6.net/marmoute-wip/mercurial/ -r d61062a8e69c
>> update: warn about other topological heads on bare update
>>
>> A concern around the user experience of Mercurial is user getting stuck on there
>> own topological branch forever. For example, someone pulling another topological
>> branch, missing that message in pull asking them to merge and getting stuck on
>> there own local branch.
>>
>> The current way to "address" this concern was for bare 'hg update' to target the
>> tipmost (also latest pulled) changesets and complain when the update was not
>> linear. That way, failure to merge newly pulled changesets would result in some
>> kind of failure.
>>
>> Yet the failure was quite obscure, not working in all cases (eg: commit right
>> after pull) and the behavior was very impractical in the common case
>> (eg: issue4673).
>>
>> To be able to change that behavior, we need to provide other ways to alert a
>> user stucks on one of many topological head. We do so with an extra message after
>> bare update:
>>
>>    1 other heads for branch "default"
>>
>> Bookmark get its own special version:
>>
>>    %i other divergent bookmarks for "%s"
>
> I somewhat got interrupted in the update of this commit message and 
> never noticed.
>
> The last thing I wanted to says is:
>
> - yes the message is not greate
> - yes it lack a hint that explain how to handle the situation (see in 
> code comment),
>
> But I would like some message to get it so that we can move forward with 
> the core of this work, changing the default destination for update and 
> all the other nicety we can get from there.
>
> I expect use to iterate on this message/hint over the 3 month between 
> now and the release.

This all looks sweet to me.