Renaming git tags results in inconsistency

Question

After renaming a git tag "1.0" to "1.5" with

Click to copy

git tag 1.5 1.0
git tag -d 1.0
git push origin :refs/tags/1.0

my git repository seems to be in an inconsistent state. Here is the git describe output:

Click to copy

warning: tag '1.0' is really '1.5' here
1.0-97-g88085b2

it should return 1.5-... now

the git fsck --tags output:

Click to copy

Checking object directories: 100% (256/256), done.
tagged commit aad9477bba4bcf44ea34ea9693aeffc98527ff01 (1.0) in b96ce67583239e198f9e2aff5175176d65779044
Checking objects: 100% (3975/3975), done.

How can I remove the dangling reference to the deleted tag? Is this the right way for renaming tags?

Answer 1

I've run into the same issue a few minutes ago. None of the answers already presented dealt with the real issue which is getting rid of the message warning: tag 'foo' is really 'bar' here and getting git describe to just list the new name of the tag. This was especially important in my case, as my build system uses git describe to record into the build what sources were used to make the build.

Replicating the Problem

I can replicate the issue by doing this:

Click to copy

$ git tag foo --annotate -m"original message"
$ git tag bar foo
$ git tag -d foo
$ git describe 
warning: tag 'foo' is really 'bar' here
foo

(The --annotate flag above is redundant as -m implies --annotate, but I've included it for emphasis.) I've tried to replicate the problem with a lightweight tag but was not able to do so. So to replicate the issue, an annotation is necessary.

Fixing the Problem

Some of this involves pushing over things that have peen pushed already but I find myself in agreement with David Culp when he says:

However, there are times it just isn't worth the long-term pain of an inaccurate (messy) history and the short-term pain is worth it.

Once you are stuck with the warning: tag 'foo' is really 'bar' here, then you must do:

Click to copy

$ git tag bar bar -m"original message" --force
$ git describe 
bar

Adapt as needed if the message needs changing.

To delete the old tag if it was already pushed:

Click to copy

$ git push origin :refs/tags/foo

To update the new tag if it was already pushed:

Click to copy

$ git push origin refs/tags/bar

Avoiding the Problem

To avoid the problem in the first place you'd have to create bar with:

Click to copy

$ git tag bar foo -m"original message"

Answer 2

To reiterate the standard caution whenever someone suggests rewriting history (or in this instance, retagging history) -- if you can avoid it, don't do it.

However, there are times it just isn't worth the long-term pain of an inaccurate (messy) history and the short-term pain is worth it.

If that is the case, the following article gives the steps needed: How to Rename a Tag Already Pushed to a Remote git Repo.

Basic steps are:

Click to copy

git tag new_tag old_tag
git push --tags
git push origin :refs/tags/old_tag
git tag -d old_tag