Bookmarks in core?
mpm at selenic.com
Mon Dec 6 10:38:14 CST 2010
On Mon, 2010-12-06 at 12:44 +0100, Didly Bom wrote:
> Hi Matt,
[oh no, a gigantic email]
> The first thing that I noticed is that when you discuss the "Basic
> desirable tag properties" you set as a requirement that tags must be
> "In history". I think that here you are in fact mixing two different
> requirements, one of which is certainly essential while the other one
> is not. In particular, I think that tags must “_have_ history".
> In section five you "Explore the alternate solution space". In there
> you have the section "What if we had separate revlogs for tags that
> weren't part of normal history?" where you say that:
> "This would also be significantly more baroque and confusing from the
> user perspective ("There's a whole separate normally-invisible history
> of tags?")."
> I think that this statement is not backed up by facts and in fact the
> opposite may be true! Where you _imagine_ a question such as "There's
> a whole separate normally-invisible history of tags?" I _get_ (on a
> day to day basis!) questions such as "Why does creating a tag create a
> new commit??", "Why does the "tag commit" appear as a child of the
> current revision?" and so on! So I believe that at most the fact that
> tags are "in history" is a User Interface decision.
Correct, I could have chosen five years ago to have a separate history.
I think this would have been a terrible choice, because most Mercurial
users would then never understand tags -at all- and their problems with
them would be even more mysterious.
Consider pull -r: most users can figure out why that doesn't work, even
if they can't figure out what they were supposed to do. But in a
parallel history approach, pull -r would still -serve the same purpose-
and thus work the same way. And only expert users who knew about the
secret tag history would be able to figure it out.
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel