Hi Michal,

Michal Novotny wrote:

> currently, if I try to create a tag that has tilde "~"  in name, an
> error is raised. E.g.
>
> $ git tag rpkg-util-1.4~rc1
> fatal: 'rpkg-util-1.4~rc1' is not a valid tag name.

As Ævar mentioned, this is disallowed to prevent a collision with
Git's revision specifying syntax.

While I'm sympathetic to wanting the tag name to match the version
number used by the package manager, the line has to be drawn
somewhere.  "git help check-ref-format" describes the current
namespace:

        Git imposes the following rules on how references are named:

        1. They can include slash / for hierarchical (directory)
           grouping, but no slash-separated component can begin with a
           dot . or end with the sequence .lock.

        2. They must contain at least one /. This enforces the
           presence of a category like heads/, tags/ etc. but the
           actual names are not restricted. If the --allow-onelevel
           option is used, this rule is waived.

        3. They cannot have two consecutive dots .. anywhere.

        4. They cannot have ASCII control characters (i.e. bytes whose
           values are lower than \040, or \177 DEL), space, tilde ~,
           caret ^, or colon : anywhere.

        5. They cannot have question-mark ?, asterisk *, or open
           bracket [ anywhere. See the --refspec-pattern option below
           for an exception to this rule.

        6. They cannot begin or end with a slash / or contain multiple
           consecutive slashes (see the --normalize option below for
           an exception to this rule)

        7. They cannot end with a dot ..

        8. They cannot contain a sequence @{.

        9. They cannot be the single character @.

       10. They cannot contain a \.

If anything, I suspect the current namespace is too wide.  For
example, it has issues with Unicode normalization in filenames on some
platforms, and it allows some potentially problematic characters like
` and |.

So my first instinct is to recommend that you apply some mapping
between your packager manager's version syntax and Git's tag syntax
--- e.g. using -rc1 as Ævar suggested, or using urlencoding %7Erc1 as
you hinted.

That isn't to say that this would be impossible to loosen.  But my
worry is that it's hard to decide where to draw the line: there are a
number of sets of names that might want to be valid tags, and it is
hard to say which are worth the complexity of expanding the set of
valid ref names.  That's why my first reaction is to look around for
another way to accomplish your goal.

Thanks,
Jonathan

Reply via email to