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 jos...@codesourcery.com
