list mirror (unofficial, one of many)
 help / color / Atom feed
From: Jonathan Nieder <>
To: Michal Novotny <>
Cc:, Ævar Arnfjörð Bjarmason <>
Subject: Re: allow "~" to be present in a tag name
Date: Tue, 13 Mar 2018 17:07:43 -0700
Message-ID: <> (raw)
In-Reply-To: <>

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

	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.


      parent reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-13  8:11 Michal Novotny
2018-03-13  9:07 ` Ævar Arnfjörð Bjarmason
2018-03-13  9:36   ` Michal Novotny
2018-03-13 10:09     ` Ævar Arnfjörð Bjarmason
2018-03-13 11:35       ` Michal Novotny
2018-03-15  8:39       ` Ævar Arnfjörð Bjarmason
2018-03-14  0:07 ` Jonathan Nieder [this message]

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:

AGPL code for this site: git clone public-inbox