39 votes

git fatal:Aucune balise ne peut décrire <numéro de SHA1>.

J'utilise les balises en les appliquant aux versions de nuit. Plus tard, je veux utiliser la sortie de describe --tags --match <latest tag> pour me dire à quel point mes images sont éloignées de la construction nocturne. C'est pour les tests d'assurance qualité.

Je viens de rencontrer une erreur dans un clone qui est plus ancien que l'étiquette actuelle. J'ai lancé git fetch --tags, donc je vois le tag dans la sortie de git tag, mais quand je lance git describe --tags --match <tagname> J'obtiens fatal: No tags can describe <head sha1 version number> . Je ne peux pas faire un git pull pour mettre à jour l'espace de travail à ce stade. Pourquoi cela se produit-il et existe-t-il une solution ? Merci de votre compréhension.

26voto

modle13 Points 465

Je viens de rencontrer cette erreur avec git version 2.8.3 et commande git describe --abbrev=0 .

Le problème est que, bien que le tag existe dans l'origine et que mon dépôt local soit à jour, le tag n'a pas de message de validation.

L'erreur a été résolue après que j'ai réétiqueté le commit avec un message d'étiquetage :

git tag v1.1.1 -m 'some message'

20voto

jrudolph Points 3726

Une autre explication peut être que le référentiel a été cloné avec un fichier depth=xyz (qui Travis le fait par défaut ). Dans ce cas, l'historique peut être interrompu avant la balise la plus récente.

Techniquement, le clonage avec depth=xyz crée un clone peu profond avec des entrées dans .git/shallow qui décrivent où couper l'histoire. Quand git describe parcourt ensuite l'historique, il se peut qu'il atteigne ce point limite et qu'il arrête de chercher une balise. Cela se produit même si vous avez recherché des balises manuellement après le clone superficiel initial avec la commande git fetch --tags .

Si tel est le cas, vous devez unshallow le référentiel (ou créer un clone complet (suffisant) en premier lieu). Voir Comment convertir un clone Git superficiel en clone complet ? pour résoudre le problème.

12voto

CharlesB Points 27070

Cela se produit parce que vous ne récupérez que l'étiquette, et non l'historique des livraisons de l'étiquette. git describe utilise cet historique, ce qui explique l'erreur.

La seule solution consiste à récupérer l'historique du repo contenant le tag qui vous intéresse, en utilisant la commande git fetch <remote-name> .

1voto

Valentin Despa Points 3540

J'ai rencontré cette erreur lorsque j'ai créé un tag git basé sur une référence git.

Il semble que la référence git n'était pas "in master" et que cela a causé des problèmes.

La solution a donc consisté à trouver la référence du commit approprié dans master et à recréer le tag.

0voto

Sandro Points 276

Pour moi, cela a fonctionné après avoir utilisé git pull au lieu de git fetch .

Améliorer les solutions déjà fournies : Ma balise git avait déjà un message de balise et git fetch <remote-name> n'a pas aidé dans mon cas non plus.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X