another confusing bookmark behaviour

Christian Widmer cwidmer at gmail.com
Wed Sep 10 13:26:35 UTC 2014


hi

i ended up with a repository where i can update infinitely and mercurial is
constantly applying changes to my working directory. it therefore flips
between the active bookmark and the tip of the branch (default).

how to reproduce

> hg init
> hg book @
> hg commit -m'1st commit on active bookmark'
> hg commit -m'2nd commit on active bookmark'
> hg up 0
> hg commit -m'3rd commit anonymous on rev0'

ok now lets see

> hg sum
parent: 2:9ed439247664 tip
 add file2
branch: default
commit: (clean)
update: 1 new changesets, 2 branch heads (merge)


@  2: tip
 |
 | o  1: @
 |/
 o  0:

> hg up -c
updating to active bookmark @
1 files updated, 0 files merged, 1 files removed, 0 files unresolved

> hg sum
parent: 1:1813c62021e8
 change file1
branch: default
bookmarks: *@
commit: (clean)
update: 1 new changesets, 2 branch heads (merge)


 o  2: tip
 |
 | @  1:  @
 |/
 o  0:



> hg up -c
2 files updated, 0 files merged, 0 files removed, 0 files unresolved

how we are back to where we started. this can be continued forever. this is
rather confusing. update moves away from the current active bookmark to the
tip but but the bookmarks stays active still. after update moves away from
the tip to the active bookmark

a) if parent != tip and parent == active bookmark => update to tip
b) if parent == tip and parent != active bookmark => move to bookmark

once the bookmark uses is magic magnetic power (as it it active) and pulls
me over.  but if i am already at the bookmark then it looses its magnetic
power and tip rules the world ;P

i am following the evolution of bookmarks since several years and they are
still  confusing. bookmarks seams not to fit very well into the traditional
behavior of mercurial. i wonder whether they will ever reach the point to
become straight forward (as mercurial's traditional reputation was). but my
personal impression is that the odds and edges are increasing. often new
features and backward-compat don't go very well and create corner cases
which lead to wired and confusing behaviors.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140910/ada1fb35/attachment-0002.html>


More information about the Mercurial mailing list