„would clobber existing tag“ in Git beheben.
Git meldet „would clobber existing tag“, wenn ein fetch ein vorhandenes lokales Tag durch ein anderes Objekt ersetzen würde. Vergleiche beide Tag-Referenzen, sichere die lokale Referenz und aktualisiere nur dieses Tag, wenn die Remote-Version maßgeblich ist.
Die sichere Lösung
Suche das in der Fehlermeldung genannte Tag. Vergleiche die lokalen und die Remote-Objekt-IDs, erstelle eine lokale Sicherung und erzwinge den fetch nur für dieses geprüfte Tag, wenn die Remote-Version richtig ist. Erzwinge nicht alle Tags und pushe keinen Ersatz zum Remote.
Annotierte Tags haben eigene Objekt-IDs. Zwei Tag-Objekte können auf denselben Commit zeigen und sich dennoch in Nachricht oder Signatur unterscheiden. Vergleiche deshalb die Tag-Referenzen und ihre dereferenzierten Ziele, bevor du entscheidest, was sich geändert hat.
1. Das genaue Tag prüfen
Ersetze v1.2.3 durch das in der Fehlermeldung genannte Tag und origin durch dein Remote. Diese Befehle ändern keine Referenzen.
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^{}'Der erste Befehl zeigt die Objekt-ID des lokalen Tags. Der zweite folgt einem annotierten Tag bis zu seinem Zielobjekt. Die Ausgabe des Remotes zeigt die Tag-Referenz und bei einem annotierten Tag eine auf ^{} endende Zeile mit seinem dereferenzierten Ziel.
Verwende die hier gezeigten vollständigen Referenznamen: Eine Präfixsuche nach v1.2.3 könnte auch v1.2.30 einschließen. Wenn das Remote kein passendes Tag hat, brich ab. Dieses Verfahren ist kein Grund, das lokale Tag zu löschen.
2. Die ursprüngliche lokale Referenz sichern
Erstelle ein lokales Wiederherstellungs-Tag, bevor du etwas ersetzt. Das leere letzte Argument verlangt, dass der Sicherungsname noch nicht verwendet wird.
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.3Beide Objekt-IDs müssen übereinstimmen. Dadurch bleibt das ursprüngliche Tag-Objekt einschließlich Nachricht und Signatur eines annotierten Tags erhalten. Scheitert das Erstellen, weil die Sicherung schon existiert, wähle einen neuen Namen und prüfe ihn, bevor du fortfährst.
Bewahre die Sicherung auf, bis die Abweichung geklärt ist. Sie bleibt lokal, solange du sie nicht pushst. Verwende für diese Reparatur nicht git push --tags.
3. Nur das geprüfte Tag aktualisieren
Führe diesen Schritt erst aus, nachdem du bestätigt hast, dass das Remote-Tag maßgeblich ist und die Sicherung existiert. Das führende + erlaubt nur den Ersatz dieser konkreten lokalen Referenz.
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 deaktiviert das automatische Folgen weiterer Tags. --no-prune und --no-prune-tags deaktivieren für diesen fetch sowohl das normale Pruning als auch konfiguriertes Tag-Pruning, damit die Reparatur nicht ausgeweitet wird. Es wird weder ein Branch noch ein Remote-Tag gepusht oder ersetzt.
Vergleiche das abgerufene Tag-Objekt und sein dereferenziertes Ziel mit den zuvor geprüften Remote-IDs. Ändert sich das Remote während der Reparatur, brich ab und untersuche den Fall, bevor du das Tag für ein Release verwendest. Die Sicherung benennt weiterhin dein ursprüngliches Objekt.
Warum Git die Aktualisierung ablehnt
Seit Git 2.20 verlangt fetch ein ausdrückliches force, um eine vorhandene refs/tags/*-Referenz zu ersetzen. Diese Regel gilt auch dann, wenn die beiden Ziele durch die Commit-Abstammung verbunden sind. Tags werden nicht nach den Fast-Forward-Regeln für Branches aktualisiert.
Wenn dein lokales Tag das richtige Release bezeichnet, behalte es und stimme dich mit der Projektpflege ab. Das Ersetzen eines veröffentlichten Remote-Tags verändert, was andere unter demselben Versionsnamen erhalten.
Offizielle Git-Referenzen
Prüfe zuerst und ändere dann nur die kleinstmögliche Referenz.
FluxGit vereint Tags, Repository-Pflege und geschützte Operationen in einem Desktop-Git-Client für macOS, Windows und Linux. Nutze die Befehle oben, um diesen Git-Fehler zu untersuchen, bevor du eine Referenz änderst.