Re: [RFC] Tag namespaces in git.

[Roland McGrath <roland at hack dot frob dot com>]

In the other threads I mentioned two issues that give me reservations about
expanding the use of tags.

1. Cleaning up tags after deletion is hairy.
   "There are scripts."  Doesn't matter.  Until it's a core built-in git
   operation as easy as 'git remote prune origin' is for branch names,
   the presumption must be that people won't have the litter cleaned out of
   their local repositories.

2. Utility of 'git describe' output.  There are two issues with this:

   a. A slash-delimited name space for tags means that the useful
      'git describe' results will look like 'release/glibc-2.16-NN-XXXXXXX'.
      This requires extra massaging to use the tag name as a
      directory name for 'git archive --prefix=' or a tar file name.

   b. Tags in the common repository for things other than official
      releases or similar globally interesting events pollute the
      match set for 'git describe'.  With a structured name space,
      people can use 'git describe --match=release/\*' or the like.
      But it gets hairier.

   The whole 'git describe' problem is mitigated if people are only
   making private name space tags for commits that are not part of
   any trunk or release-branch history.  But if we set any policy
   encouraging people to make their own tags, even if it were said
   to be restricted to such commits, people would make errors or
   fail to understand/observe the policy, and we'd get pollution
   before long to be sure.