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

login
register
mail settings
Submitter Waldemar Kornewald
Date Nov. 8, 2015, 12:18 a.m.
Message ID <CAA5tf+-mrtaKtWEoL=KwLbZ_bXZ4wjSkc9mS7_iVAZZT1Rv0LQ@mail.gmail.com>
Download mbox | patch
Permalink /patch/11324/
State Changes Requested
Headers show

Comments

Waldemar Kornewald - Nov. 8, 2015, 12:18 a.m.
# 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 ."
Ryan McElroy - Nov. 9, 2015, 10:01 p.m.
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?

>
> diff -r f9984f76fd90 -r d71b2904941b mercurial/commands.py
> --- a/mercurial/commands.py Wed Nov 04 15:17:52 2015 -0600
> +++ b/mercurial/commands.py Sun Nov 08 00:03:31 2015 +0100
> @@ -6666,6 +6666,12 @@
>       if rev is None or rev == '':
>           rev = node
>
> +    # 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 ."
> +    if rev == '.' and repo._activebookmark:
> +        rev = repo._activebookmark
> +
>       wlock = repo.wlock()
>       try:
>           cmdutil.clearunfinished(repo)
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel
Gregory Szorc - Nov. 9, 2015, 11:55 p.m.
On Mon, Nov 9, 2015 at 2:01 PM, Ryan McElroy <rm@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.
Augie Fackler - Nov. 10, 2015, 3:02 a.m.
On Mon, Nov 09, 2015 at 03:55:34PM -0800, Gregory Szorc wrote:
> On Mon, Nov 9, 2015 at 2:01 PM, Ryan McElroy <rm@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.

As a counterpoint, 'hg up :.' probably still works even with this
patch to deactivate the current bookmark.

(Not sure how I actually feel, just offering up a neat trick I learned
sometime in 2015.)


> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel
Waldemar Kornewald - Nov. 10, 2015, 9:24 a.m.
On Nov 10, 2015 00:56, "Gregory Szorc" <gregory.szorc@gmail.com> wrote:
>
> 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.
>

I'd really like to know, why do you deactivate bookmarks, at all?
Also, why do you stay on the same revision? Why not do all development
with bookmarks?

In Git you even get a big warning (you're in detached mode) whenever
you deactivate a branch.

We always mark our main branch with an @ bookmark because otherwise
clone, pull -u, and update would switch to tip - which is some
arbitrary branch. Also, introducing bookmarks in a later step needs to
be coordinated with all developers (so they all hg up @). It's really
unfortunate that bookmarks are such a second-class citizen (not used
by default, not enforced like in Git).

Greetings,
Waldemar
Martin von Zweigbergk - Nov. 10, 2015, 11:55 a.m.
On Nov 10, 2015 01:25, "Waldemar Kornewald" <wkornewald@gmail.com> wrote:
>
> On Nov 10, 2015 00:56, "Gregory Szorc" <gregory.szorc@gmail.com> wrote:
> >
> > 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.
> >
>
> I'd really like to know, why do you deactivate bookmarks, at all?

I do it to avoid updating the bookmark. Sometimes I have @ checked out and
I want create a commit and send it to the mailing list.

> Also, why do you stay on the same revision? Why not do all development
> with bookmarks?

Especially if it's just a single commit, there is not much reason to create
a bookmark for it.

>
> In Git you even get a big warning (you're in detached mode) whenever
> you deactivate a branch.

That's because git will gc commits that are not pointed to by anything. Hg
does not gc.

>
> We always mark our main branch with an @ bookmark because otherwise
> clone, pull -u, and update would switch to tip - which is some
> arbitrary branch. Also, introducing bookmarks in a later step needs to
> be coordinated with all developers (so they all hg up @). It's really
> unfortunate that bookmarks are such a second-class citizen (not used
> by default, not enforced like in Git).

I used git for many years (and contributed to the project) before my
current project made me work on hg. When I switched to hg, my initial
reaction was to use bookmarks all the time, just like I was used to using
branches with git. Soon, I had gotten used to commits not getting gc'd and
I stopped using bookmarks for simple changes. After a bit longer, when I
still used bookmarks for larger features, I would sometimes realize there's
a better way of doing part of the feature and I would check out a commit or
two from the tip, make another commit it two and have a new topological
branch without a bookmark. Frequently, that new branch turned out to really
be better, and I would have to move the bookmark and strip/obsolete the
previous attempt. This happened frequently enough that the benefit of
having a label for the feature seemed smaller than the cost of updating
where it pointed to. I almost never use bookmarks anymore. I have not felt
that I have trouble finding commits.

I'm now trying out the experimental "topic" extension, which lets you label
a feature without the trouble of moving the label between tips of the
feature branch.

I never use -u with pull. And I haven't collaborated on a shared bookmark.

>
> Greetings,
> Waldemar
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel
Gregory Szorc - Nov. 12, 2015, 12:16 a.m.
On Tue, Nov 10, 2015 at 1:24 AM, Waldemar Kornewald <wkornewald@gmail.com>
wrote:

> On Nov 10, 2015 00:56, "Gregory Szorc" <gregory.szorc@gmail.com> wrote:
> >
> > 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.
> >
>
> I'd really like to know, why do you deactivate bookmarks, at all?
> Also, why do you stay on the same revision? Why not do all development
> with bookmarks?
>
> In Git you even get a big warning (you're in detached mode) whenever
> you deactivate a branch.
>
> We always mark our main branch with an @ bookmark because otherwise
> clone, pull -u, and update would switch to tip - which is some
> arbitrary branch. Also, introducing bookmarks in a later step needs to
> be coordinated with all developers (so they all hg up @). It's really
> unfortunate that bookmarks are such a second-class citizen (not used
> by default, not enforced like in Git).
>

I'm mostly in the same boat as Martin: I typically don't use labels
(bookmarks) because I don't need to. I find that `hg wip` (
http://jordi.inversethought.com/blog/customising-mercurial-like-a-pro/) +
proper commit messages tell me everything I need to know. Labels are
avoidable overhead to me.

However, I do interact with repos that have bookmarks (notably @). So I
find myself activating and/or moving the "global bookmarks" frequently.
When it comes time for me to write new commits, I need to deactivate the
bookmark, hence the `hg up .` trick.

Patch

diff -r f9984f76fd90 -r d71b2904941b mercurial/commands.py
--- a/mercurial/commands.py Wed Nov 04 15:17:52 2015 -0600
+++ b/mercurial/commands.py Sun Nov 08 00:03:31 2015 +0100
@@ -6666,6 +6666,12 @@ 
     if rev is None or rev == '':
         rev = node

+    # 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 ."
+    if rev == '.' and repo._activebookmark:
+        rev = repo._activebookmark
+
     wlock = repo.wlock()
     try:
         cmdutil.clearunfinished(repo)