How to fix “would clobber existing tag” in Git.
Git reports “would clobber existing tag” when a fetch would replace an existing local tag with a different object. Compare both tag refs, preserve the local ref, and update that single tag only if the remote version is authoritative.
The safe answer
Find the tag named in the error. Compare the local and remote object IDs, create a local backup, then force-fetch only that verified tag if the remote version is correct. Do not force every tag or push a replacement to the remote.
Annotated tags have their own object IDs. Two tag objects can point to the same commit while differing in their message or signature; compare the tag refs and their peeled targets before deciding what changed.
1. Inspect the exact tag
Replace v1.2.3 with the tag named in the error and origin with your remote. These commands do not change refs.
git show-ref --verify refs/tags/v1.2.3
git rev-parse 'refs/tags/v1.2.3^{}'
git ls-remote --tags origin 'refs/tags/v1.2.3' 'refs/tags/v1.2.3^{}'The first command shows the local tag object ID. The second resolves through an annotated tag to its underlying object. The remote output shows the tag ref and, for an annotated tag, a line ending in ^{} for its peeled target.
Use the full ref names shown here: a prefix search for v1.2.3 could also include v1.2.30. If the remote has no matching tag, stop; this procedure is not a reason to delete the local tag.
2. Preserve the original local ref
Create a local recovery tag before replacing anything. The empty final argument requires the backup name to be unused.
git update-ref refs/tags/backup/v1.2.3 refs/tags/v1.2.3 ""
git rev-parse refs/tags/v1.2.3 refs/tags/backup/v1.2.3Both object IDs must match. This preserves the original tag object, including an annotated tag's message and signature. If creation fails because the backup already exists, choose a new backup name and verify it before continuing.
Keep the backup until the disagreement is resolved. It stays local unless you push it; do not use git push --tags for this repair.
3. Update only the verified tag
Run this only after confirming that the remote tag is authoritative and the backup exists. The leading + authorizes replacement of this specific local ref.
git fetch --no-tags --no-prune --no-prune-tags origin '+refs/tags/v1.2.3:refs/tags/v1.2.3'
git show-ref --verify refs/tags/v1.2.3
git rev-parse 'refs/tags/v1.2.3^{}'--no-tags disables automatic following of other tags. --no-prune and --no-prune-tags disable configured pruning for this fetch so that it cannot widen the repair. No branch or remote tag is pushed or replaced.
Verify the fetched tag object and peeled target against the remote IDs you inspected. If the remote changed during the repair, stop and investigate before using the tag for a release. The backup still names your original object.
Why Git rejects the update
Since Git 2.20, fetch requires an explicit force to replace an existing refs/tags/* reference. This rule applies even when the two targets are related by commit ancestry; tags are not updated using branch fast-forward rules.
If your local tag is the correct release, keep it and coordinate with the maintainer. Replacing a published remote tag changes what other users receive under the same version name.
Official Git references
Inspect first, then change the smallest possible ref.
FluxGit brings tags, repository hygiene and guarded operations into a desktop Git client for macOS, Windows and Linux. Use the commands above to diagnose this Git error before changing a ref.