[PATCH 2 of 2 STABLE] bookmarks: resolve divergent bookmarks when moving active bookmark forward

[Sean Farley]

On Mon, Apr 29, 2013 at 7:49 PM, Kevin Bullock
<kbullock+mercurial at ringworld.org> wrote:
> On 29 Apr 2013, at 5:38 PM, Sean Farley wrote:
>
>> # HG changeset patch
>> # User Sean Farley <sean.michael.farley at gmail.com>
>> # Date 1367272357 18000
>> #      Mon Apr 29 16:52:37 2013 -0500
>> # Branch stable
>> # Node ID ddd8b869e48d8d353905e9c0b2964c3795a9dc88
>> # Parent  d6ff913a84d296fc6d1ed129351eb215d7e6920e
>> bookmarks: resolve divergent bookmarks when moving active bookmark forward
>>
>> This patch resolves divergent bookmarks between the current active bookmark
>> MARK and the new destination. This situation can arise when pulling new
>> changesets, abandoning your current changesets actively bookmarked with MARK
>> via strip, and then doing a bare update. The non-divergent but active bookmark
>> MARK is then moved to a common ancestor of the new changesets and the abandoned
>> changesets.
>>
>> Test coverage is added.
>>
>> diff --git a/mercurial/bookmarks.py b/mercurial/bookmarks.py
>> --- a/mercurial/bookmarks.py
>> +++ b/mercurial/bookmarks.py
>> @@ -169,24 +169,28 @@
>>                 del marks[mark]
>>                 deleted = True
>>     return deleted
>>
>> def update(repo, parents, node):
>> +    deletefrom = parents
>>     marks = repo._bookmarks
>>     update = False
>>     cur = repo._bookmarkcurrent
>>     if not cur:
>>         return False
>>
>>     if marks[cur] in parents:
>>         old = repo[marks[cur]]
>>         new = repo[node]
>> +        divs = [repo[b] for b in marks
>> +                if b.split('@', 1)[0] == cur.split('@', 1)[0]]
>> +        deletefrom = [b.node() for b in divs if b.descendant(new) or b == new]
>
> How come these two calculations are slightly different from those in patch 1?

Mainly because of the surrounding code: in patch 1 there was already
some code that used ancestors() while in this code there was already
some code that used descendant(). I didn't know the ramifications (and
code churn) of using a lazy generator here.