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