allow "~" to be present in a tag name

allow "~" to be present in a tag name

[Michal Novotny]

Hello,

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.

Now, actually it would be very cool if tilde was allowed in a tag name
because we would like to use it for tagging pre-releases of (not-only
rpm) packages.

Is there some deep technical reason why tilde cannot be present in a
tag name? I tried that e.g.

git tag rpkg-util-1.4%rc1

but percentage sign does not seem to be particular fitting for
pre-release marking.

Thank you
clime

Re: allow "~" to be present in a tag name

[Ævar Arnfjörð Bjarmason]

On Tue, Mar 13 2018, Michal Novotny jotted:

> Hello,
>
> 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.
>
> Now, actually it would be very cool if tilde was allowed in a tag name
> because we would like to use it for tagging pre-releases of (not-only
> rpm) packages.
>
> Is there some deep technical reason why tilde cannot be present in a
> tag name? I tried that e.g.

Yes, because a trailing tilde is part of git's rev syntax, see "man
git-rev-parse", or try in any repo:

    git show HEAD
    git show HEAD~2
    git show HEAD^~2

etc.

Although I guess git could learn to disambiguate that form from the tag
you're trying to create.

> git tag rpkg-util-1.4%rc1
>
> but percentage sign does not seem to be particular fitting for
> pre-release marking.
>
> Thank you
> clime

Re: allow "~" to be present in a tag name

[Michal Novotny]

On Tue, Mar 13, 2018 at 10:07 AM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
> On Tue, Mar 13 2018, Michal Novotny jotted:
>
>> Hello,
>>
>> 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.
>>
>> Now, actually it would be very cool if tilde was allowed in a tag name
>> because we would like to use it for tagging pre-releases of (not-only
>> rpm) packages.
>>
>> Is there some deep technical reason why tilde cannot be present in a
>> tag name? I tried that e.g.
>
> Yes, because a trailing tilde is part of git's rev syntax, see "man
> git-rev-parse", or try in any repo:
>
>     git show HEAD
>     git show HEAD~2
>     git show HEAD^~2

Right, reading the man pages:

<rev>~<n>, e.g. master~3
           A suffix ~<n> to a revision parameter means the commit
object that is the <n>th generation ancestor of the named commit
object, following only the first
           parents. I.e.  <rev>~3 is equivalent to <rev>^^^ which is
equivalent to <rev>^1^1^1. See below for an illustration of the usage
of this form.

Would it be acceptable to disallow only ~<n> (<n> as [0-9]+) in a tag
name but allow ~[^0-9].*, i.e. if the immediately following symbol
after '~' is a letter, do not
interpret ~ as a special character. Could it work?

Thank you!
clime

>
> etc.
>
> Although I guess git could learn to disambiguate that form from the tag
> you're trying to create.
>
>> git tag rpkg-util-1.4%rc1
>>
>> but percentage sign does not seem to be particular fitting for
>> pre-release marking.
>>
>> Thank you
>> clime

Re: allow "~" to be present in a tag name

[Ævar Arnfjörð Bjarmason]

On Tue, Mar 13 2018, Michal Novotny jotted:

> On Tue, Mar 13, 2018 at 10:07 AM, Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>>
>> On Tue, Mar 13 2018, Michal Novotny jotted:
>>
>>> Hello,
>>>
>>> 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.
>>>
>>> Now, actually it would be very cool if tilde was allowed in a tag name
>>> because we would like to use it for tagging pre-releases of (not-only
>>> rpm) packages.
>>>
>>> Is there some deep technical reason why tilde cannot be present in a
>>> tag name? I tried that e.g.
>>
>> Yes, because a trailing tilde is part of git's rev syntax, see "man
>> git-rev-parse", or try in any repo:
>>
>>     git show HEAD
>>     git show HEAD~2
>>     git show HEAD^~2
>
> Right, reading the man pages:
>
> <rev>~<n>, e.g. master~3
>            A suffix ~<n> to a revision parameter means the commit
> object that is the <n>th generation ancestor of the named commit
> object, following only the first
>            parents. I.e.  <rev>~3 is equivalent to <rev>^^^ which is
> equivalent to <rev>^1^1^1. See below for an illustration of the usage
> of this form.
>
> Would it be acceptable to disallow only ~<n> (<n> as [0-9]+) in a tag
> name but allow ~[^0-9].*, i.e. if the immediately following symbol
> after '~' is a letter, do not
> interpret ~ as a special character. Could it work?

We could make that work, with some caveats:

 1) The syntax we've reserved for refnames is quite small, and my bias
    at least would be to say you should just make a tag like
    rpkg-util-1.4-rc1 instead (as e.g. git.git and linux.git do).

    Carving out an exception like this also means we couldn't use
    ~[^0-9].* for anything magical in the future.

    But I think that's a rather small objection, we have other syntax
    escape hatches, and we're unlikely to use ~[^0-9].* as some new
    magic.

 2) If we patch git to accept this, you'll be creating refs that aren't
    inter-operable with previous versions of git.

    This is a big deal. E.g. you'll happily create this special ref,
    then try to push it to github, and they'll croak because that's an
    invalid ref to them. Ditto some co-worker of yours who's using an
    older version of git.

    FWIW if you manually create such a tag e.g. for-each-ref will emit
    'warning: ignoring ref with broken name' and just not show it.

>>
>> etc.
>>
>> Although I guess git could learn to disambiguate that form from the tag
>> you're trying to create.
>>
>>> git tag rpkg-util-1.4%rc1
>>>
>>> but percentage sign does not seem to be particular fitting for
>>> pre-release marking.
>>>
>>> Thank you
>>> clime

Re: allow "~" to be present in a tag name

[Michal Novotny]

On Tue, Mar 13, 2018 at 11:09 AM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
> On Tue, Mar 13 2018, Michal Novotny jotted:
>
>> On Tue, Mar 13, 2018 at 10:07 AM, Ævar Arnfjörð Bjarmason
>> <avarab@gmail.com> wrote:
>>>
>>> On Tue, Mar 13 2018, Michal Novotny jotted:
>>>
>>>> Hello,
>>>>
>>>> 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.
>>>>
>>>> Now, actually it would be very cool if tilde was allowed in a tag name
>>>> because we would like to use it for tagging pre-releases of (not-only
>>>> rpm) packages.
>>>>
>>>> Is there some deep technical reason why tilde cannot be present in a
>>>> tag name? I tried that e.g.
>>>
>>> Yes, because a trailing tilde is part of git's rev syntax, see "man
>>> git-rev-parse", or try in any repo:
>>>
>>>     git show HEAD
>>>     git show HEAD~2
>>>     git show HEAD^~2
>>
>> Right, reading the man pages:
>>
>> <rev>~<n>, e.g. master~3
>>            A suffix ~<n> to a revision parameter means the commit
>> object that is the <n>th generation ancestor of the named commit
>> object, following only the first
>>            parents. I.e.  <rev>~3 is equivalent to <rev>^^^ which is
>> equivalent to <rev>^1^1^1. See below for an illustration of the usage
>> of this form.
>>
>> Would it be acceptable to disallow only ~<n> (<n> as [0-9]+) in a tag
>> name but allow ~[^0-9].*, i.e. if the immediately following symbol
>> after '~' is a letter, do not
>> interpret ~ as a special character. Could it work?
>
> We could make that work, with some caveats:
>
>  1) The syntax we've reserved for refnames is quite small, and my bias
>     at least would be to say you should just make a tag like
>     rpkg-util-1.4-rc1 instead (as e.g. git.git and linux.git do).

There is kind of clash of symbolics with rpm world. In rpm world, the component
after the last dash in a package full (versioned) name is usually
reserved for a downstream
packager who increments it as he/she adds patches to the original
sources. I will
need to do slightly more research here of what is possible.

Thank you so far!

>
>     Carving out an exception like this also means we couldn't use
>     ~[^0-9].* for anything magical in the future.
>
>     But I think that's a rather small objection, we have other syntax
>     escape hatches, and we're unlikely to use ~[^0-9].* as some new
>     magic.
>
>  2) If we patch git to accept this, you'll be creating refs that aren't
>     inter-operable with previous versions of git.
>
>     This is a big deal. E.g. you'll happily create this special ref,
>     then try to push it to github, and they'll croak because that's an
>     invalid ref to them. Ditto some co-worker of yours who's using an
>     older version of git.
>
>     FWIW if you manually create such a tag e.g. for-each-ref will emit
>     'warning: ignoring ref with broken name' and just not show it.
>
>>>
>>> etc.
>>>
>>> Although I guess git could learn to disambiguate that form from the tag
>>> you're trying to create.
>>>
>>>> git tag rpkg-util-1.4%rc1
>>>>
>>>> but percentage sign does not seem to be particular fitting for
>>>> pre-release marking.
>>>>
>>>> Thank you
>>>> clime

Re: allow "~" to be present in a tag name

[Jonathan Nieder]

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

Re: allow "~" to be present in a tag name

[Ævar Arnfjörð Bjarmason]

On Tue, Mar 13 2018, Ævar Arnfjörð Bjarmason jotted:

> On Tue, Mar 13 2018, Michal Novotny jotted:
>
>> On Tue, Mar 13, 2018 at 10:07 AM, Ævar Arnfjörð Bjarmason
>> <avarab@gmail.com> wrote:
>>>
>>> On Tue, Mar 13 2018, Michal Novotny jotted:
>>>
>>>> Hello,
>>>>
>>>> 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.
>>>>
>>>> Now, actually it would be very cool if tilde was allowed in a tag name
>>>> because we would like to use it for tagging pre-releases of (not-only
>>>> rpm) packages.
>>>>
>>>> Is there some deep technical reason why tilde cannot be present in a
>>>> tag name? I tried that e.g.
>>>
>>> Yes, because a trailing tilde is part of git's rev syntax, see "man
>>> git-rev-parse", or try in any repo:
>>>
>>>     git show HEAD
>>>     git show HEAD~2
>>>     git show HEAD^~2
>>
>> Right, reading the man pages:
>>
>> <rev>~<n>, e.g. master~3
>>            A suffix ~<n> to a revision parameter means the commit
>> object that is the <n>th generation ancestor of the named commit
>> object, following only the first
>>            parents. I.e.  <rev>~3 is equivalent to <rev>^^^ which is
>> equivalent to <rev>^1^1^1. See below for an illustration of the usage
>> of this form.
>>
>> Would it be acceptable to disallow only ~<n> (<n> as [0-9]+) in a tag
>> name but allow ~[^0-9].*, i.e. if the immediately following symbol
>> after '~' is a letter, do not
>> interpret ~ as a special character. Could it work?
>
> We could make that work, with some caveats:
>
>  1) The syntax we've reserved for refnames is quite small, and my bias
>     at least would be to say you should just make a tag like
>     rpkg-util-1.4-rc1 instead (as e.g. git.git and linux.git do).
>
>     Carving out an exception like this also means we couldn't use
>     ~[^0-9].* for anything magical in the future.
>
>     But I think that's a rather small objection, we have other syntax
>     escape hatches, and we're unlikely to use ~[^0-9].* as some new
>     magic.
>
>  2) If we patch git to accept this, you'll be creating refs that aren't
>     inter-operable with previous versions of git.
>
>     This is a big deal. E.g. you'll happily create this special ref,
>     then try to push it to github, and they'll croak because that's an
>     invalid ref to them. Ditto some co-worker of yours who's using an
>     older version of git.
>
>     FWIW if you manually create such a tag e.g. for-each-ref will emit
>     'warning: ignoring ref with broken name' and just not show it.

Not to beat this dead horse, but just for the list archive: FWIW there's
other commands that'll just plain die if they find such a ref, e.g. git
gc:

    fatal: bad object refs/tags/foo~rc1
    error: failed to run repack

So if we ever expand the scope of allowed refs we'd need to first adjust
the setting and then wait a long time, least downgrading git hard break
some commands.

>>>
>>> etc.
>>>
>>> Although I guess git could learn to disambiguate that form from the tag
>>> you're trying to create.
>>>
>>>> git tag rpkg-util-1.4%rc1
>>>>
>>>> but percentage sign does not seem to be particular fitting for
>>>> pre-release marking.
>>>>
>>>> Thank you
>>>> clime