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

[Kevin Bullock]

On 11 Apr 2013, at 3:23 PM, Matt Mackall wrote:

> On Thu, 2013-04-11 at 19:49 +0000, Durham Goode wrote:
>> On 4/11/13 12:00 PM, "Kevin Bullock" <kbullock+mercurial at ringworld.org>
>> wrote:
>> 
>>> Just to clarify, I think we're worried about (at least) two cases here:
>>> 
>>> --A--B*
>>>  \
>>>   D--E
>>> 
>>> and
>>> 
>>> --A--B*--C
>>>  \
>>>   D--E
>>> 
>>> where A, B, and C are local changes and D & E were pulled from upstream.
>>> AFAIU, your patch would report "nothing changed" in the former case, but
>>> update to C in the latter. (For those following along, we currently try
>>> to update to E in either case, and abort.)
>>> 
>>> Seeing "nothing changed" is a good hint, but only helps with the first
>>> case (and only helps partially anyway).
>> 
>> In case #2 the old behavior (and the new) would update to C since C is the
>> branch tip right? So no change there in #2.
> 
> Yes. But not because it's the tipmost descendant of '.'. So there's also
> this case:
> 
> -A-B*-C
>  \
>   D----E  <- E is numerically higher than C, and thus is the branch tip

This is precisely what I meant with my case #2 (should've used more dashes). Say Alice is on B. She pulls from the team shared repo and gets C (added by Bob), D, and E (added by Eve, who --forced a push).

If I understand the patch correctly, then with this change, Alice gets C where before she would get an aborted attempt to update to E. But either way, I'm pretty sure Alice shouldn't get _silently_ updated to C.

The same is probably true of case 1: Alice shouldn't just get "0 files updated, 0 files merged, 0 files removed, 0 files unresolved", she should get a hint that there's another head there (if it's on the same named branch, and not non-divergently bookmarked?).

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock