Issues with hg update -C and bookmarks

Sean Farley sean at farley.io
Tue Jul 14 22:37:58 UTC 2015


Marc Strapetz <marc.strapetz at syntevo.com> writes:

> On 14.07.2015 19:28, Sean Farley wrote:
>>
>> Marc Strapetz <marc.strapetz at syntevo.com> writes:
>>
>>> With the following setup:
>>>
>>> $ hg init
>>> $ touch x
>>> $ hg commit -A "initial import"
>>> $ touch y
>>> $ hg commit -A -m "y added"
>>> $ hg checkout 0
>>> $ touch z
>>> $ hg commit -A -m "z added"
>>> $ hg up 1
>>> $ hg bookmark bm
>>>
>>> There will be default with two diverged heads at r1 and r2 and a
>>> bookmark on r1.
>>>
>>> $ hg summary
>>> parent: 1:4009599f6088
>>>    y added
>>> branch: default
>>> bookmarks: *bm
>>> ...
>>>
>>> Starting from this setup, following behavior is rather unexpected to me:
>>>
>>> (1) hg update -C . will loose the active bookmark
>>>
>>> $ hg update -C .
>>> $ hg summary
>>> parent: 1:4009599f6088
>>>    y added
>>> branch: default
>>> bookmarks: bm
>>> commit: (clean)
>>> update: 1 new changesets, 2 branch heads (merge)
>>>
>>> I would expect to see bookmark "*bm" still active.
>>>
>>> (2) hg upgdate -C checks out r2 (expected), but leaves bookmark bm
>>> active (unexpected)
>>>
>>> $ hg update -C
>>> $ hg summary
>>> parent: 2:eb990d6c7e06 tip
>>>    z added
>>> branch: default
>>> commit: (clean)
>>> update: 1 new changesets, 2 branch heads (merge)
>>>
>>> $ hg bookmarks
>>>    * bm                        1:4009599f6088
>>>
>>> I would probably expect that bookmark "bm" isn't active anymore. What's
>>> the meaning of an active bookmark which is not checked out?
>>
>> You've hit a bit of a sore spot with bookmarks. I was hoping Ryan
>> McElroy (hereby thrown under the bus) would be the one to submit some
>> patches in this direction but haven't seen any yet.
>>
>> In my vision, 'hg up' without any argument should *not* move the
>> bookmark.
>
> That's fine. But shouldn't the "active" flag be reset? In the UI, we are 
> rendering the active bookmark bold, leading the user to believe he has 
> checked out the respective commit. For sure, that is easy to fix, but 
> I'm wondering whether this isn't some kind of inconsistency?

No, you're right that it's an inconsistency. I have been meaning to take
a serious stab at it but have been sidetracked with $work.



More information about the Mercurial mailing list