update, revsets and dashes in tag names

[Idan Kamara]

On Fri, Jan 13, 2012 at 9:33 PM, Dennis Brakhane <brakhane at googlemail.com>wrote:

> update allows the user to specify a revset, in which case the first
> revision of the set is updated to.
> This leads to very confusing behaviour when tag names with dashes and
> typos are involved.
> Consider the following:
>
>
> $ hg tags
> tip                               13:b246f7e4cf99
> foo-bar-1                         12:f96659fd95fa
> foo-6                             10:6ad4b2eedbec
> foo-5                              8:af125b0f9970
> foo-4                              6:970031f93a37
> foo-3                              4:3cfc3862199f
> foo-2                              2:9af0fd2588fb
> foo                                0:88e9fe256745
> $ hg up -q foo && hg id
> 88e9fe256745 foo
> $ hg up -q foo-6 && hg id
> 6ad4b2eedbec foo-6
> $ hg up -q foo-7 && hg id
> 88e9fe256745 foo
>

Is this a correct tl;dr of your post:
How do I update to a tag with dashes without interpreting it otherwise if
the tag doesn't exist?

If so...

$ hg up "tag('foo-7')"
abort: tag 'foo-7' does not exist


> $ hg up -q foo-bar-2 && hg id
> abort: unknown revision 'bar'!
>

> A tag named "foo-6" exists, so update updates to it. However, there is
> (not yet) a tag named "foo-7", but our
> user does not know that and simply tries to update to it. (Or simply
> missed the 6 key and hit 7 instead)
>
> update can't find "foo-7", so it re-interprets it as a revset,
> meaning "all revisions tagged foo without the revision 7", and
> therefore updates to tag foo. Naturally, there is no error,
> so our hypothetical newbie user reasonably assumes he is now in
> "release 7" or whatever, when in fact
> he just checked out a really old revision.
>
> The "foo-bar-2" case is not so bad, just confusing (and actually the
> one I tried to write a patch for, when I realized
> the underlying reason/problem)
>
> The question is, can we do something about it? Disallowing revsets in
> update certainly is not an option,
> neither is disallowing dashes, plus signs, tildes and carets (colons
> are already disallowed) in tags; apart from
> the problem of already existing tags, limiting tag names to handle a
> corner case in update seems like a wrong thing to me.
>
>
> I currently can't think (for update) of a useful revset specification
> that does include a dash (or plus sign), that does not
> also include at least a parenthesis (or space):
>
> "xxx-yyy" -> useless, simply write xxx instead.
> "author(me)-file(foo)" -> (kinda) useful, update to the most recent
> changeset by me that didn't involve file "foo"
>
> Therefore, in case of a revision parameter to update that does include
> a dash or plus, but no parenthesis, we could either choose not to try
> revsets at all, or output a warning: "no tag xxx-yyy found, assuming
> you meant a revset"
>
> That would still leave tags containings carets or tildes vulnerable,
> but I double people are actually using them in tags that often.
>
> I would write a patch if we can agree on how it should be handled.
>
> Opinions?
>
> Greetings,
>  Dennis
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120113/a82af62f/attachment.html>