Bookmarks with hg update question

[Ludovic Chabant]

> That's usually not enough state. For this, I implemented 'tracking' in
> my remotebookmarks extension. I'll be slowly moving parts of that into
> core soon (hopefully).

Your remotebookmarks extension is to me the only way to solve this
correctly -- I'm not sure the Mercurial team should do much to the
existing CLI until you've done this work of moving stuff to the core.

Unless I'm missing something, it seems to me that the problem is that
Mercurial doesn't have enough information to know what the commits ahead
of a bookmark are:

* They could be commits that logically belong to the same lineage. E.g.
your bookmark is a lightweight branch that you work on with other
people, and you just pulled some commits from a co-worker. In that case,
you want the bookmark to logically advance to your co-worker's "head"
(which would, in Git and remotebookmarks, be represented with a
"remote/" prefixed bookmark of the same name).

* They could be commits that belong to a different lineage. Someone
created a new lightweight branch that started from your bookmark. In
this case, you don't want the bookmark to advance. Again, in Git and
remotebookmarks, the work coming from whoever did that wouldn't have any
bookmark associated with it, or would have a differently named bookmark.
The "remote/" prefixed bookmark would still be in the same place, and
therefore "hg up" wouldn't advance you.

The remotebookmark extension gives Mercurial the necessary information
IMHO -- because "hg up" SHOULD DEFINITELY advance a bookmark IN SOME
CASES. Differentiating between those cases will always be ambiguous
until then, leading to either overly complicated rules and "gotchas" or
just plain broken things.
-- 
 l u d o .
 . 8 0 17 80