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