`type commit` in einem annotierten Tag in git

Lesezeit: 2 Minuten

Benutzer-Avatar
hgiesel

Echo eines annotierten Tags in Git mit git cat-file -p <hash-of-tag> produziert sowas:

object <sha1-hash>
type commit
tag 0.0.1
tagger My Name (...)

Description of tag

object zeigt in meinem Fall auf ein Commit-Objekt. type commit impliziert, dass dies nicht unbedingt der Fall sein muss. Gibt es Fälle, in denen annotierte Tags nicht auf Commits verweisen?

Ja: Ein annotiertes Tag-Objekt kann auf ein anderes annotiertes Tag-Objekt oder sogar direkt auf einen Baum oder Blob zeigen. Diese sind jedoch alle ziemlich selten.

Das git rev-parse Befehl – ​​eigentlich Git im Allgemeinen; rev-parse ist nur die benutzerorientierte Schnittstelle zu den Routinen – hat die Vorstellung, ein Tag oder sogar ein Commit zu „schälen“, um einen bestimmten Zielobjekttyp zu erreichen. Wenn Sie beispielsweise den Baum anzeigen möchten, der an ein Commit oder Tag oder eine Hash-ID angehängt ist:

git rev-parse whatever^{tree}

dreht die whatever part in was auch immer es ist, und versucht dann, bis zu dem Punkt “aufzubohren”, wo wir ein Baumobjekt erhalten. Ob whatever ein annotiertes Tag ist, folgt dies dem Tag wiederholt zu seinem Objekt, bis es an einem Nicht-Tag ankommt, das per Definition entweder ein Commit, ein Baum oder ein Blob ist:

  • Wenn wir einen Baum erreicht haben, sind wir fertig.
  • Wenn wir ein Commit erreicht haben, hat jedes Commit einen Baum der obersten Ebene, also extrahieren wir den Baum dieses Commits.
  • Wenn wir einen Blob erreicht haben, ist kein Baum zu finden, also der Befehl (ob das ist git rev-parse oder zB git diff oder git diff-tree) Fehler aus.

Befehle wie git diff-tree das will ein <tree-ish> automatisch jedes Argument, das Sie ihnen geben, in den Baum umwandeln, als ob Sie die hinzugefügt hätten ^{tree} Suffix. Wie Sie vielleicht erwarten, gibt es auch ^{commit} und ^{blob} Suffixe. Da ist auch ein ^{tag} Suffix, das lediglich bestätigt, dass etwas tatsächlich ein Tag ist (da kein anderer Objekttyp aufgelöst werden kann zu ein Tag), und es gibt eine ^{} Suffix bedeutet “ein Tag in sein Objekt auflösen”, dh alle annotierten Tags abziehen und dann das verbleibende Objekt abrufen.

Die vollständigen Regeln sind in beschrieben die gitrevisions-Dokumentation. Beachten Sie, dass sich nicht jeder Git-Befehl wie beschrieben verhält: insbesondere git checkout versucht, sein Argument als Zweignamen zu behandeln, bevor es dem sechsstufigen Prozess in gitrevisions folgt. Das heißt, wenn der Name foo kann sowohl ein Tag sein und ein Zweig, git checkout foo findet die Zweig (dh checkt aus refs/heads/foo), sondern git show foo zeigt das Ergebnis der Auflösung der Schild.

Ja, Sie können jedes Git-Objekt markieren, indem Sie seinen Hash übergeben oder auf andere Weise darauf verweisen git tag.

Neben einem commita tree (die Verzeichnisliste, auf die in einem Commit verwiesen wird), blob (die Dateiinhalte, auf die in einem Baum verwiesen wird) oder sogar a tag kann auch in einem Tag vorkommen.

1011100cookie-check`type commit` in einem annotierten Tag in git

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy