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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux