[PATCH 2 of 3]: update: don't lose active bookmark when updating to the "." revision

Gregory Szorc gregory.szorc at gmail.com
Mon Nov 9 17:55:34 CST 2015


On Mon, Nov 9, 2015 at 2:01 PM, Ryan McElroy <rm at fb.com> wrote:

>
> On 11/7/2015 4:18 PM, Waldemar Kornewald wrote:
>
> # HG changeset patch
> # User Waldemar Kornewald <wkornewald>
> # Date 1446937411 -3600
> #      Sun Nov 08 00:03:31 2015 +0100
> # Node ID d71b2904941b99ca194683009ca224c8b17d2272
> # Parent  f9984f76fd90e439221425d751e29bae17bec995
> update: don't lose active bookmark when updating to the "." revision
>
> this is more intuitive and captures the user's intention, especially
> when cancelling an uncommitted merge via "hg up -C ."
>
>
> I like the idea, and in fact we talked about this use case at the recent
> mercurial sprint. The main problem I see with this approach is Backward
> Compatibility. That being said, I actually think this way would be better
> than the current behavior, but don't know if it's better enough to break
> the BC.
>
> See the sprint notes here: https://titanpad.com/hg36sprint
>
> In particular, look at the "Feature Branch Discussion Summary" section.
> The agreement we came to at the sprint is thus:
>
> * introduce an "active()" or "activebm()" revset to refer to the currently
> active bookmark
> * Since '.' is a reserved bookmark name, we can use it to refer to
> "activebm()" when it's clear you're referring to a bookmark
> * Introduce a -B option to update to allow creating and updating to
> bookmarks
>
> So I'd suggest moving in that direction since it will be less resistance.
> Ie, make it so that "hg update 'active()'" has the behavior you're building
> here.
>
> What do others think?
>

I frequently use `hg up .` to deactivate the current bookmark because it is
less typing than `hg book -i`. I concede I probably shouldn't be doing
this. But I'm lazy and a power user. I'm -0 on this patch because it
changes my workflow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20151109/6fb86297/attachment.html>


More information about the Mercurial-devel mailing list