So just call it "X.1"
  and be done with it.

. The insane thing.
  You really want to call the new version "X" too, 'even though'
  others have already seen the old one. So just use 'git tag -f'
  again, as if you hadn't already published the old one.

However, Git does *not* (and it should not) change tags behind
users back. So if somebody already got the old tag, doing a
'git pull' on your tree shouldn't just make them overwrite the old
one.

If somebody got a release tag from you, you cannot just change
the tag for them by updating your own one. This is a big
security issue, in that people MUST be able to trust their
tag-names.  If you really want to do the insane thing, you need
to just fess up to it, and tell people that you messed up. You
can do that by making a very public announcement saying:

------------
Ok, I messed up, and I pushed out an earlier version tagged as X. I
then fixed something, and retagged the *fixed* tree as X again.

If you got the wrong tag, and want the new one, please delete
the old one and fetch the new one by doing:

	git tag -d X
	git fetch origin tag X

to get my updated tag.

You can test which tag you have by doing

	git rev-parse X

which should return 0123456789abcdef.. if you have the new version.

Sorry for the inconvenience.
------------

Does this seem a bit complicated?  It *should* be. There is no
way that it would be correct to just "fix" it automatically.
People need to know that their tags might have been changed.


On Automatic following
~~~~~~~~~~~~~~~~~~~~~~

If you are following somebody else's tree, you are most likely
using remote-tracking branches (eg. `refs/remotes/origin/master`).
You usually want the tags from the other end.

On the other hand, if you are fetching because you would want a
one-shot merge from somebody else, you typically do not want to
get tags from there.  This happens more often for people near
the toplevel but not limited to them.  Mere mortals when pulling
from each other do not necessarily want to automatically get
private anchor point tags from the other person.

Often, "please pull" messages on the mailing list just provide
two pieces of information: a repo URL and a branch name; this
is designed to be easily cut&pasted at the end of a 'git fetch'
command line:

------------
Linus, please pull from

	git://git..../proj.git master

to get the following updates...
------------

becomes:

------------
$ git pull git://git..../proj.git master
------------

In such a case, you do not want to automatically follow