Re: extra head

[Daniel J Sebald]

I've read some of the bookmark background on HG, and I get the point of 
them now.  They are, in fact, a branch--but as Jordi pointed out, an 
ephemeral branch.  Once that branch is merged via a bookmark 
modification (deleting it, repositioning a similarly named bookmark 
somewhere else), there is no record of the branch or name.  That 
behavior is different from tagged branches.

One problem is that, I think, developers really want to treat the 
default tip as a tagged branch and not a bookmark.  The ramifications 
are small if a bookmark becomes divergent (just merging is the thing to 
do...because essentially that is what HG is supposed to do, and then 
discard that branch as though it never existed).  If a developer fails 
to configure their HG to automatically advance the @ bookmark upon 
commits, then the bookmark isn't pointing at the latest code. 
Subsequent users who

hg update @

might make some edits that conflict with what already exists.  Nothing 
is lost of course, it's just that HG will complain, or launch the 
merging tool, or something.

I'm wondering if the clean that Ben is using

hg update -C @

is something that shouldn't be done with bookmarks.  I think what might 
have happened is that Ben updated his repository and working copy to the 
latest.  Made some changes and pushed that.  But in between someone 
might have pushed some items and moved the @ bookmark.  (Or an equally 
plausible scenario is that Ben pulled from the repository when the 
bookmark wasn't pointing at the most recent code.)  Perhaps somehow the 
-C clean is detaching Ben's @ bookmark from the @ bookmark in the 
default branch (which has been repositioned).  Hence the complaint:

divergent bookmark @ stored as @default

I wonder if without the -C option mercurial would have successfully 
tracked the bookmark movement, merged then discard the temporary branch.

Dan