[PATCH 2 of 2] summary: show when active bookmark moved

Kevin Bullock kbullock+mercurial at ringworld.org
Wed Jan 30 19:29:33 CST 2013


On 30 Jan 2013, at 6:23 PM, Matt Mackall wrote:

> On Wed, 2013-01-30 at 12:22 -0600, Kevin Bullock wrote:
>> Thus we now have the situation that 'hg bookmarks' shows the
>> current-but-not-active bookmark, but 'hg summary' gives no indication
>> that an update will go to said bookmark. I'd like to fix this, but my
>> patch isn't the right way to do it (as I mentioned before).
> 
> It probably ought to look like this:
> 
> $ hg sum
> parent: 18473:692cbda1eb50 tip
> revset: evaluate sub expressions correctly (issue3775)
> branch: stable
> bookmarks: *@
> commit: 15 unknown (clean)
> update: (current)
> 
> $ hg pull
> <some pull that moves @ out from under us>
> 
> $ hg sum
> parent: 18472:37100f30590f 
> test-rebase: add another test for rebase with multiple roots
> branch: stable
> bookmarks: (@)
> commit: 15 unknown (clean)
> update: 1 new changesets (update)
> 
> Note the last line in particular: summary's calculation of the default
> update target probably needs attention. We possibly even want something
> like an update() revset predicate that tells us where we're going.

Yeah, that's kinda the direction I was thinking in.

> Also, something I encountered while constructing the last example: when
> we update to an ancestor of the active bookmark, we might want the
> bookmark to remain active, but not move:
> 
> $ hg up @ <- we're on @
> $ hg up <- we go to @ if @ moved
> $ hg up @^ <- we hop off @, oops
> $ hg up <- we go to the branch tip, @ stops getting updated
> 
> Or, more expansively, we might want to only drop the active bookmark if
> we move to a commit outside of (::x or x::). So, for instance:
> 
> o-a-o-o- at -o-o-x   (. = @)
>     \   \
>      u   o-o-y
> 
> hg up -> no-op, we're at @
> hg up a -> we leave @ active, but go backwards
> hg up x -> we advance @ to x
> hg up y -> we advance @ to y
> hg up u -> @ is deactivated
> 
> But we probably don't want to do this in the case of updating to
> symbolic markers like tags, branches, other bookmarks, so this might be
> too complex.

Hmm, I think it's a good idea offhand, but you might be right about the complexity. On the other hand, there's -never- been a notion in Mercurial of an 'active tag'. On the third hand, named branches actually already exhibit something akin to the same behavior ('hg update' goes to tipmost named-branch head).

Relatedly, we probably shouldn't require --force to move a bookmark to an ancestor(?) or descendant of its current position. (We also shouldn't require --force to activate a bookmark that already points to the working dir.)

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock



More information about the Mercurial-devel mailing list