I know bookmarks are supposed to move on commits. When merging a bookmarked revision into another head, the bookmark moves to the merging commit. The merging commit is a child of the previous bookmarked revision, so technically this just conforms to the "move on commit" idea. However, is this a desired behavior in a typical "switch-and-merge-branches-repeatedly" workflow? I don't think so. Example: I have a named branch 'dev' for working on bigger changes. At the same time I have multiple short-living bookmarked heads to work on smaller changes. Below is an example, main, fix1 and feature2 are bookmarked heads: dev main fix1 feature2 o o o o \ | | / . . . . The problem here is that if I do a 'hg merge main' within the 'dev' branch, that bookmark moves into the dev branch, technically correct according to the bookmark definition, but semantically wrong. When merging in a bookmarked revision, the referenced bookmark should not move. Thoughts?
I agree with obs.
Totally agree. This should be the default.
I believe bookmarks.track.current is what you want, the problem is that it is in the help text of the extension which is shadowed by the help of the command. with this enabled, you need to explicitly update to a bookmark for it to be moved next commit (merge or not). Maybe this should be the default? put this in your hgrc [bookmarks] track.current = True
I still think bookmarks from "the other head" (parent 2 of the working dir before the commit) of merges should never be moved onto the merged-to line of the DAG. Independent of the track.current setting.
Happy to hear you agree here. I enabled the track.current option and now the bookmark does not move when it gets merged in. As you mentioned, I think this should be the default behavior. I would even go further and make the 'track.current = True' behavior the default one for any commits. That way bookmarks are more similar to branches. Personally I cannot think of situations where I would prefer the 'track.current = False' behavior (but for sure there use cases for that). If track.current should be enabled or disabled by default depends on which behavior is more useful in the majority of cases and which behavior matches the mental model most new users have when they start using bookmarks (latter one is not easy to answer).
Please test this. It's fixed since 1.8. track.current is now the default behaviour.
Though the track.current options appears to be enabled by default (i.e. it works as expcected on regular commits), the initial problem that bookmarks move on merges still exists. Actually it is worse now since the workaround to enable the option is not possible anymore. Here's an interactive shell session illustrating the problem: http://pastebin.com/AsbN9t08
updated title
I've written a fix for this issue and wrote a corresponding test for the test suite. If nobody is working on this already, I would send my patch to the mailing list. However, just want to make sure this isn't already tackled.
Fixed by: changeset: 13806:8ba08a16e4e0 user: David Soria Parra <dsp@php.net> date: Mon Mar 14 23:50:28 2011 +0100 summary: bookmarks: do not forward merged bookmark (issue1877)
Fixed by http://selenic.com/repo/hg/rev/4d958d1bb072 David Soria Parra <dsp@php.net> bookmarks: do not forward merged bookmark (issue1877) (please test the fix)
works as expected, thanks
Re-resolving auto-reopened issue
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:03 EDT --- This bug was previously known as _bug_ 1877 at http://mercurial.selenic.com/bts/issue1877