Branch and tag deletions

[Joseph Myers]

On Wed, 4 Dec 2019, Segher Boessenkool wrote:

> > My script has a special case to use the name 
> > refs/heads/releases/gcc-2.95.2.1-branch with "-branch" in there, because 
> > there's also refs/tags/releases/gcc-2.95.2.1, and while technically git 
> > allows you to have refs/heads/<name> and refs/tags/<name> both present, 
> > it's a bad idea to do so because "git checkout releases/gcc-2.95.2.1" 
> > would be confusing if you expected it to check out one of the tag and the 
> > branch and git chose to check out the other.  (Other such ambiguities are 
> > dealt with by putting ".0" on the names of some tags.)
> 
> And, as I said before, a release branch is a totally different animal
> from releases (release tags).  We do this correctly now, let's keep it
> that way?

By convention, a branch in SVN lives in /branches and a branch in git 
lives in refs/heads/, whereas a tag in SVN lives in /tags and a tag in git 
lives in refs/tags/.  This doesn't require any particular naming 
convention within those directories, but it's helpful to avoid actually 
having a branch and a tag with the same name.  My script is implementing 
one possible naming convention suggested by Richard (and thus trying to 
make the names of release branches and tags a bit more consistent than 
they are at present).

The avoidance of '.' in branch and tag names is, I'm pretty sure, a legacy 
of CVS restrictions on valid names for branches and tags.  Those 
restrictions are not relevant to git or SVN; if picking any new convention 
it seems appropriate for the tag for GCC 10.1 to say "10.1" somewhere in 
its name rather than "10_1".

-- 
Joseph S. Myers
joseph@codesourcery.com