[PATCH 4 of 6 V2] merge: include obsolete calculation for branchtips

[Sean Farley]

pierre-yves.david at ens-lyon.org writes:

> On 01/14/2014 01:51 PM, Sean Farley wrote:
>> pierre-yves.david at ens-lyon.org writes:
>>
>>> On 01/13/2014 01:42 AM, Pierre-Yves David wrote:
>>>> On 01/12/2014 02:25 PM, Sean Farley wrote:
>>>>> # HG changeset patch
>>>>> # User Sean Farley<sean.michael.farley at gmail.com>
>>>>> # Date 1383779296 21600
>>>>> #      Wed Nov 06 17:08:16 2013 -0600
>>>>> # Node ID b97f7e3553f1694abd360e30c0e4a9eac59f393a
>>>>> # Parent  460212c85977dbeec5007558fa26293a4a0d11f4
>>>>> merge: include obsolete calculation for branchtips
>>>>>
>>>>> Previously, a bare update would ignore any successor changesets thus
>>>>> potentially leaving you on an obsolete head. This happens commonly when there
>>>>> is an old bookmark that hasn't been moved forward which is the motivating
>>>>> reason for this patch series.
>>>>>
>>>>> Now, we will check for successor changesets if two conditions hold:
>>>>>     1) we are doing a bare update
>>>>>     2) *and* the branchtip returned normally is obsolete
>>>> This is a slghlty different version of what we discussed in New-York.
>>>>
>>>> 2) should be "if current working directory parent is a head and obsolete"
>>>>
>>>> If update can move up along standard topology it should alway just do it.
>>> This is actually even more different, This patch update to tipmost
>>> foreground. You want to update to tip most successors set in that case.
>> Ok, that clarify things. I'll resend.
>
> Final clarification of expected behavior.
>
> If changeset have descendant:
>      update to tipmost descendant
> else (changeset is head) if changeset is obsolete:
>      update to tipmost successors (not foreground, actual successors of 
> this changeset)
> else (no idea were to go)
>      sit down and complain about the situation if possible

Ok, I'll resend with this feedback.