Why tags should never be removed from server?

Question

Reading Gerrit docs, it says:

[...] users should be really knowledgeable about git, 
for instance knowing why tags never should be removed from a server

It doesn't elaborate on this statement. I don't see any problem with it and I can't find any info about it either.

So, why tags should never be removed from server?

Canoodle

Answer 1

Why you shouldn't remove a remote tag is explained at the bottom of http://git-scm.com/docs/git-tag, section "On Re-tagging".

In short: if a collaborator has already fetched the tag once, it won't update it after you change it. Hence the tag becomes rather useless since it represents a commit A in the remote repo, but it may represent a commit B in the repos of a few developpers

Hegira

Answer 2

If you push annotated tags, they are supposed to represents "tags when a project reaches a stable release point worth remembering in history."

Since a project owner in Gerrit has the right to delete tags, the documentation add that warning in order for other users relying on said tags to not be surprised (or to be properly warned) if that tag were to change (or to be deleted).

See the section "Enforcing site wide access policies"

By granting the Owner access right on the refs/* to a group, Gerrit administrators can delegate the responsibility of maintaining access rights for that project to that group.

In a corporate deployment it is often necessary to enforce some access policies. An example could be that no-one can update or delete a tag, not even the project owners.
The ALLOW and DENY rules are not enough for this purpose as project owners can grant themselves any access right they wish and, thus, effectively override any inherited access rights from the "All-Projects" or some other common parent project.

That is why Gerrit proposes:

Make sure no one can update or delete a tag

This requirement is quite common in a corporate deployment where reproducibility of a build must be guaranteed. To achieve that we block push permission for the Anonymous Users in "All-Projects":

[access "refs/tags/*"]
  push = block group Anonymous Users
  create = group Project Owners
  pushTag = group Project Owners

Bueschel

Answer 3

The 'best practice' here is not to do it. But there may be some legit. reason to...

Not all tags are important to downstream processes (CI/CD,releases). (Not all tags have to be annotated, either) Also, Many tags between releases and between milestones can often be incomplete sub-projects that have little functional meaning aside from documentation.

For example, devel tags between 1.3.8.5-final (released) and 1.3.8.6-alpha could consist of some subset of tags made merely in order to get CI/CD to trigger and tests performed. Tags 1.3.8.6-feature-3343-0 through 1.3.8.6-feature-3343-5 could all be incomplete and unstable. IMO there is little harm in removing them.

There's usually not an important reason to do so; but there may be cases where you want to remove confusion, such as when a developer makes tag 1.3.8.5-feature-3343-6 but meant to create 1.3.8.6-feature-3343-6. In that case you may want to clarify the history of code progression by removing the mistake, and there would be no significant consequences since there would be no downstream use for the tag

Saturn