[PATCH] bookmarks: resolve divergent bookmark when moving forward

[Sean Farley]

Kevin Bullock writes:

> On 28 Mar 2013, at 5:06 PM, Sean Farley wrote:
>
>> Kevin Bullock writes:
>> 
>>> On 28 Mar 2013, at 1:50 PM, Sean Farley wrote:
>>> 
>>>> Kevin Bullock writes:
>>>> 
>>>>> On 27 Mar 2013, at 10:38 PM, Sean Farley wrote:
>>>>>> $ hg init test && cd test
>>>>>> $ echo a>a
>>>>>> $ hg ci -Am0
>>>>>> $ echo b>>a
>>>>>> $ hg ci -m1
>>>>>> $ hg book -r 0 @
>>>>>> $ hg book -r 1 @default
>>>>>> $ hg up @
>>>>>> $ hg up
>>>>>> 
>>>>>> You'll see that the divergent is still lying around when it should be
>>>>>> taken care of automatically. Applying this patch will fix that up but I
>>>>>> wanted to make sure other behavior wasn't affected.
>>>>> 
>>>>> Normally this shouldn't happen in a real-life situation, because no divergent bookmarks are ever _created_ unless they actually... diverge. As in, they're on different topological branches. (Note also that rebase should take care of divergent bookmarks itself.)
>>>>> 
>>>>> Do you have a real-life case where this has come up?
>>>> 
>>>> I do indeed! It was with the mercurial repo itself when I was trying out
>>>> some of Siddharth's new patches. Since I was already on '@' when I
>>>> applied the patches, '@' was moved forward. After mucking on his
>>>> patches, some time passes and I pull from crew. This creates the
>>>> divergent '@default' bookmark.
>>> 
>>> ...on a different topological branch, meaning 'hg update' won't help you here, and 'hg bookmark -r REV NAME' will require you to --force it.
>>> 
>>>> "Oh, right," I say to myself, "I'll just
>>>> create a new bookmark for sid0's patches and move '@' back to its
>>>> rightful place."
>>> 
>>> @'s "rightful place" is now where @default is. I still don't get how this patch helps the situation you describe.
>> 
>> Oops, I forgot to include the command I ran after I pulled:
>> 
>> $ hg book -r @default -f @
>> 
>> This will now have two bookmarks on the same changeset that are
>> 'divergent' which didn't make sense to me. If I move a bookmark to its
>> corresponding divergent one (or vice versa), then I would expect the
>> divergent to be considered resolved.
>
> _That_ makes sense. I think it would be sufficient to just make `hg bookmark` handle this case directly.

Ok, I can restructure the patch (add more explanation, a test, etc.) and
make `hg bookmark` handle removing the divergent bookmark.