Bookmarks in core?

[Kevin Bullock]

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock


On Dec 6, 2010, at 6:32 AM, Adrian Buehlmann wrote:

> On 2010-12-06 12:44, Didly Bom wrote:
>> 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. While your document addresses
>> most of the key issues behind the design of mercurial tags it does not
>> really address the UI issues that may be leading to the slight
>> dissatisfaction that some users (me included) have with the way tags work.
> 
> "Why does creating a tag create a newcommit??":
> 
> Because it changes a project and it is an integral part of "what
> happened" in the history of a project. There ain't no such thing as a
> separate history for anything in a specific project.
> 
> Take mercurial itself as a good example: If Matt makes a new release he
> tags a revision. That's an action done on the project as a whole. It's
> an action like "I fixed bug X by modifying line Y of file Z like this".
> 
> And quite a number of projects use tags like that and people using it
> understand it. That *is* a fact.
> 
> "Why does the "tag commit" appear as a child of the current revision?"
> 
> Tagging on anything else than the tip of the branch you want to tag
> would by silly indeed in almost all cases. You might blame mercurial for
> failing to protect you from every silly user action, but users who
> understand how mercurial records history also understand how diverging
> lines of history happen. And when forking history is probably a bad idea.

Would it be worthwhile to issue a warning when tagging at a non-head revision? (To be clear: not when -tagging- a non-head revision, only when creating a tag commit as a -new- head, as the child of a non-head revision.) hg does tend to be good at issuing guidance to users who are doing things that aren't recommended. I could work up a patch if this is desirable.

> The solution to your "problems" is: educate the users. Not: try to tweak
> core Mercurial until it starts to match what the uninformed users
> currently happen to see as the best way.
> 

> Sometimes, you have to make users unhappy at first, because they have to
> learn new paradigms or unlearn crappy old ones. As soon as they get over
> it, they will thank you that you resisted the temptation to try to
> implement their suboptimal, initial, simplistic view of the world.


Perhaps harshly stated given that we all know hg's behavior isn't going to change here. But I agree, the -last- thing you want in creating good usability is for there to be a mismatch between the conceptual model of the user and that of the software. And user education includes the cues the software gives them. One example is `hg push` aborting when it would create a new remote head. You can re-run with -f (or --new-branch) if that's what you meant to do, but hg helps you avoid doing it when you -didn't- mean to (or didn't know you shouldn't).

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock