Branch and tag deletions

Richard Earnshaw (lists) Richard.Earnshaw@arm.com
Fri Nov 29 16:44:00 GMT 2019


On 29/11/2019 16:14, Joseph Myers wrote:
> # Tags for vendor releases.
> tag/ARM/  delete
> tag/apple/gcc/  delete
> tag/csl/  delete
> tag /linaro-/ delete
> tag /microblaze-/ delete
> tag/st/GCC/  delete
> tag /ubuntu/gcc-/ delete
> tag egcs_1_0_x_redhat5_1 delete
> tag gcc-1766 delete
> tag gcc-3_2-rhl8-3_2-7 delete
> tag ix86/gcc_4_3_1_release delete

I'm not convinced these should be just deleted.  At least, not without 
the specific vendor's agreement.  But perhaps they should not be in the 
default refs/tags namespace.

The same also applies for the vendor branches, perhaps we should have 
some useful conventions for these, something like

refs/vendors/<vendor>/{heads,tags}

And similarly if users want private development trees:

refs/users/<user>/{heads,tags}

Git wouldn't pull either of these by default, which would help to 
minimise the amount of data pulled, but adding them to a pull spec would 
be trivial.

I also wonder whether in the standard namespaces we should be a bit more 
structured, so that only releases use single-level tags, and everything 
else goes into refs/{heads,tags}/devel.  Or we could do it the other way 
around, so all releases go into refs/{heads,tags}/releases - that makes 
finding them amongst the noise of other tag/branch names much easier.

R.



More information about the Gcc mailing list