Re: Why aren't tag refs namespaced?

Nathan Gray [off-list ref] writes:

quoted

Other workflows that use private tags are possible and they might
benefit from having separate namespaces; it is just that they are not
the workflow Git was originally designed to support.

That makes sense.

Yeah, as I said, the current behaviour aims to support a particular
workflow, e.g.

 * "git fetch --tags" uses a built-in refspec "refs/tags/*:refs/tags/*"
   and that maps a tag at the remote to the same location in the refs/
   hierarchy in the local repository.

 * "git fetch" that stores the history it fetches to local repository
   (i.e. uses refspec with non-empty RHS), when run without "--no-tags",
   fetches tags that point at commits in the fetched history from the
   remote and stores them at the same location in the refs/ hierarchy.

and does it well.

But there is nothing in Git that fundamentally forces you to follow that
pattern.  It is entirely plausible to enhance the former (i.e. --tags)
to a bool-or-string option to let you specify different refs/ hierarchy
(e.g. "--tags" would use "refs/tags/*:refs/tags/*" to map the names,
while "--tags=refs/remotes/origin/tags" might store fetched tags in
specified place that is different from refs/tags/), and to add a new
option to specify where the auto-followed tags would be stored to
enhance the latter.