Bookmarks in core?

[Matt Mackall]

On Mon, 2010-11-29 at 23:15 +0000, David Soria Parra wrote:
> On 2010-11-29, Brodie Rao <brodie at bitheap.org> wrote:
> > On Nov 30, 2010, at 6:07 AM, Matt Mackall wrote:
> >
> >> Discuss.
> >
> > Some thoughts:
> >
> > - I think the track.current option is confusing. Why not enable it by  
> > default?
> Two reasons. (1) backward compatibility. The first implementation fo bookmarks
> didn't have this flag. If we enable it, we can confuse people that use bookmarks
> without that option. 

At the risk of being villified by Peter Williams, if no one can explain
why that behavior actually makes sense and why changing it would break
any realistic use case, we might want to consider it a bug and drop it.
Moving bookmarks into core will be our last chance to fix things like
this up.

> (2) track.current is a way to emulate git's branch behavior.
> This is a 'naming for a head'. The name bookmarks suggests that you can use it
> like the bookmarks you would put into a book. If you go to the next page you probably
> will advance both bookmarks and not just one. Therefore the default beahvior is more
> related to the naming of the feature.

If you're reading a book and move two bookmarks, odds are good that one
of them is either someone else's bookmark (bad!) or a marker you've
placed to explicitly get back to the same place in the future (lots of
people litter their reference books or cookbooks with these sorts of
bookmarks).

More or less the same applies to Mercurial. It probably never makes
sense to move two bookmarks at the same time. For instance, a commit
corresponds to changing one "user context" (the current thread of
development) and updating two context pointers is probably a mistake.

-- 
Mathematics is the supreme nostalgia of our time.