That there aren't remote tracking tags is a bug, the reason to have remote tracking isn't purely to watch modifications, but to see where a ref came from.

The git version that's about to be released has a fetch.pruneTags feature I wrote which has more caveats than it should have because of missing remote tracking for tags.

There was a patch series to implement remote tracking for tags a while ago, but it's a lot of work to get right so it stalled. Hopefully it'll be re-visited.

Tags can be added (created).

Tags can be deleted (permanently destroyed, though of course with the distributed nature of git, remote tags must then be handled in a separate step).

But those are not intrinsic properties of the tag itself. Those are properties of the repo that holds the tag.

The tag itself is immutable: It is a human readable name pointing to a commit id. And, to distinguish it from a branch, it can't be updated after it is created.

Setting aside the distributed nature of git, if I delete a tag and add it again to point at a different commit id, how can the tag be considered immutable? If I step away from my desk and come back and look at a commit id, I know it is exactly the same thing as before. I can’t say the same thing about a tag.

The tag is immutable because you had to first delete it, then recreate it, to change its value. Technically the tag might have the same label (say v0.0.1), but it still is a new tag, that so happens to be labeled the same as your old immutable tag.

Same way strings in python are immutable yet still allow you to delete and recreate. Git repos are not blockchains

I don't know enough about blockchains to understand the phrase git repos are not blockchains.

If I say git log 191edc5e2e515aab1075a3f0ef23599e80be5f59 anywhere at any time it means the same thing each and every time. That is not the case with git log v0.0.1

The v0.0.1 is just a label for the tag object itself.

E.g. if you clone git.git you can see a tag for v2.16.2, the latest release. That you can re-create point to something entirely different.

But if you do:

    $ git rev-parse v2.16.2
    86aabcca24951ccfb9392014c8a379992434a7df
    $ git rev-parse v2.16.2^{commit}
    ffa952497288d29d94b16675c6789ef83850def3

You can see that the annotated tag object (GPG signature and all) is really called 86aabcca24951ccfb9392014c8a379992434a7df, and that it points to a commit ffa952497288d29d94b16675c6789ef83850def3.

That 86aabcca... is the immutable part of tags, just as commit objects are immutable.

Note that this only applies to annotated tags, lightweight tags just point to the commit object themselves, so they're really just a sort of branch name that git treats differently in not ever advancing it to another commit.

Are you confusing immutable with tamper-resistant or something along those lines?

I am not sure :/. Is there some reading material you could point me at? Thanks!