Bookmarks with hg update question

[Sietse Brouwer]

James Reynolds wrote:

> A lot this discussion in interesting, and I think this large amount of
> discussion should demonstrate that bookmarks are confusing. If they weren't,
> there wouldn't be much discussion.
>
> I'm personally still in favor of my initial proposal from earlier

I was sort of losing track of everything proposed, so here's a summary of
all ideas floated in this thread. I've left out the arguments pro and con so
as to make this e-mail more purely a summary.

This mail presents ideas as 'suggested' instead of 'proposed' because
people may have floated an idea without being a proponent.

All errors are definitely mine, because I paraphrased for brevity.
Please accept my apologies in advance for any misrepresentations I have
introduced.

For ease of reference, I've tried to give each idea a shortish name in
square brackets.

Cheers,
Sietse

Proposals
=========

[reverse behaviour]
https://www.mercurial-scm.org/pipermail/mercurial/2016-June/049644.html
https://www.mercurial-scm.org/wiki/BookmarkUpdatePlan
Sean Farley said:
> It's ok, we agreed at a previous sprint to change this. I have a
> bit-rotted patch that I will try to submit this week.
https://www.mercurial-scm.org/pipermail/mercurial/2016-June/049644.html

    The proposed solution is to treat a bookmark as a head and stay at
    the current commit when a bookmark is active.

    To preserve the current behavior a new bookmark alias will be
    introduced: `hg update -B`.

[noupdate setting]
James Reynolds suggested an hgrc setting for new behaviour, preserving
backwards compatibility:

    [bookmarks]
    https://www.mercurial-scm.org/pipermail/mercurial/2016-June/049651.html
    noupdate =

[moveonupdate setting]
https://www.mercurial-scm.org/pipermail/mercurial/2016-June/049660.html
Aaron Jensen suggested the reverse: backwards incompatibility by default,
backwards compatible behaviour recovered by activating a setting.

    [bookmarks]
    moveonupdate =

[prompt to choose default]
https://www.mercurial-scm.org/pipermail/mercurial/2016-June/049661.html
Steve Barnes suggested a combination of these two: both `moveonupdate`
and `noupdate`, and if neither is present prompt for choice.

[temporary old marker]
Steve Barnes suggested (in the same mail) that auto-moving a bookmarks
should place a temporary bookmark at the pre-move position, and should
mention that temp bookmark's existence in the output message.

[limited forward movement]
https://www.mercurial-scm.org/pipermail/mercurial/2016-June/049672.html
Scott Palmer suggested (and later disendorsed):

  * If a bookmark is active and @ is present and ahead of the current
    bookmark, then a bare `hg up` moves forward to the `@`
  * If a bookmark is active, but @ is not present and ahead, then a bare
    `hg up` moves forward to the next branchpoint
  * If no bookmark is active, then a bare hg up goes to the branch tip as
    before

[message on move]
https://www.mercurial-scm.org/pipermail/mercurial/2016-June/049674.html
Steve Barnes suggested that any operation that updates a bookmark should
output

    "Updated Bookmark: Name from Rev X to Rev Y"

`hg bookmark` already does this partially, `hg update` does not do this:

    $ hg bookmark x  # to move a bookmark forward
    moving bookmark 'x' forward from 7b43c2e53b66

    $ hg up  # to update the current bookmark
    3 files updated, 0 files merged, 0 files removed, 0 files unresolved
    updating bookmark x


Workarounds bookmark users currently use
========================================

James Reynolds asked: is there a setting that will prevent bookmarks from
moving when running `hg up`?

Andrew Fischer's team used a bashrc setting that blocks bare `hg update`

Mischa Becker used `hg up current~0` to update to a bookmark without
activating it.

David Demelier advised `hg pull -B the_bookmark_name` to put an
inadvertently moved bookmark back in its old place.