Git global tags--- evidently bad, but why?

Question

In his 2005 email to the Linux Kernel mailing list, Linus Torvalds is very emphatic that tags in git should be private and not be automatically included when fetching from others:

Pulling a regular head cannot and must not update tags. Tags are not associated with the tree, and they cannot and must not be so, exactly because that would make them global instead of private, and it would fundamentally make them not be distributed

and:

It is wrong, wrong, wrong to think that fetching somebody elses tree means that you should fetch his tags.

I am not a kernal hacker. One of the reasons I use git is to be able to edit my own code from different locations. Tags seem like a natural way to describe different versions for future reference, e.g. what works, what doesn't, what quirks exist. Thus to me it would seem helpful to have tags persist across fetches. Can someone explain what the peril of this paradigm is?

Why is having private tags so important? And what is the alternative? Should I simply make a separate branch every time I may want to flag a particular version of the code?

Answer 1

I don't know, but tags are actually fetched these days, and that has been the default for a pretty long time.

The wording in the parts you're quoting seems confusing to me when looking at it with today's git terminology, so I'd dare to claim that Linus's statement is outdated.

Answer 2

The key word there is "not automatically included." You can push and pull tags, you just have to specify it in your push/pull commands. Try git push --tags.

(Actually, tags are automatically pulled these days, but pushes must be explicit.)