Git

git-rev-parse zuletzt aktualisiert in 2.52.0

NAME

git-rev-parse - Parameter auswählen und verarbeiten

SYNOPSIS

git rev-parse [<options>] <arg>…

BESCHREIBUNG

Viele Git-Porcelain-Befehle nehmen eine Mischung aus Flags (d. h. Parameter, die mit einem Bindestrich - beginnen) und Parametern, die für den zugrunde liegenden git rev-list Befehl bestimmt sind, den sie intern verwenden, sowie Flags und Parameter für die anderen Befehle, die sie nach git rev-list verwenden. Der Hauptzweck dieses Befehls besteht darin, aufrufenden Programmen die Unterscheidung zwischen ihnen zu ermöglichen. Es gibt einige andere Betriebsmodi, die nichts mit den oben genannten "Hilfe beim Parsen von Kommandozeilenoptionen" zu tun haben.

Sofern nicht anders angegeben, erfordern die meisten Optionen und Betriebsmodi, dass Sie diesen Befehl innerhalb eines Git-Repositorys oder eines Arbeitsbaums, der sich unter der Kontrolle eines Git-Repositorys befindet, ausführen, andernfalls erhalten Sie eine Fehlermeldung.

OPTIONEN

Betriebsmodi

Jede dieser Optionen muss zuerst in der Befehlszeile erscheinen.

--parseopt: Verwendet git rev-parse im Optionsparsingmodus (siehe Abschnitt PARSEOPT unten). Der Befehl kann in diesem Modus außerhalb eines Repositorys oder eines von einem Repository kontrollierten Arbeitsbaums verwendet werden.
--sq-quote: Verwendet git rev-parse im Shell-Quoting-Modus (siehe Abschnitt SQ-QUOTE unten). Im Gegensatz zur unten stehenden Option --sq führt dieser Modus nur das Quoting durch. Mit der Eingabe des Befehls wird nichts weiter gemacht. Der Befehl kann in diesem Modus außerhalb eines Repositorys oder eines von einem Repository kontrollierten Arbeitsbaums verwendet werden.

Optionen für --parseopt

--keep-dashdash: Nur sinnvoll im Modus --parseopt. Weist den Optionsparser an, den ersten gefundenen -- statt ihn zu überspringen, auszugeben.
--stop-at-non-option: Nur sinnvoll im Modus --parseopt. Lässt den Optionsparser beim ersten Nicht-Options-Argument anhalten. Dies kann zum Parsen von Unterbefehlen verwendet werden, die selbst Optionen enthalten.
--stuck-long: Nur sinnvoll im Modus --parseopt. Gibt die Optionen in ihrer langen Form aus, falls verfügbar, und mit angehängten Argumenten.

Optionen für Filterung

--revs-only: Gibt keine Flags und Parameter aus, die nicht für den git rev-list Befehl bestimmt sind.
--no-revs: Gibt keine Flags und Parameter aus, die für den git rev-list Befehl bestimmt sind.
--flags: Gibt keine Nicht-Flag-Parameter aus.
--no-flags: Gibt keine Flag-Parameter aus.

Optionen für die Ausgabe

--default <arg>

Wenn kein Parameter vom Benutzer angegeben wird, wird stattdessen <arg> verwendet.

--prefix <arg>

Verhält sich so, als ob git rev-parse aus dem Unterverzeichnis <arg> des Arbeitsbaums aufgerufen worden wäre. Alle relativen Dateinamen werden aufgelöst, als ob sie mit <arg> präfixiert wären, und in dieser Form ausgegeben.

Dies kann verwendet werden, um Argumente für einen Befehl, der in einem Unterverzeichnis ausgeführt wird, zu konvertieren, so dass sie nach dem Wechsel in die oberste Ebene des Repositorys weiterhin verwendet werden können. Zum Beispiel

prefix=$(git rev-parse --show-prefix)
cd "$(git rev-parse --show-toplevel)"
# rev-parse provides the -- needed for 'set'
eval "set $(git rev-parse --sq --prefix "$prefix" -- "$@")"

--verify

Überprüft, ob genau ein Parameter angegeben wurde und ob dieser in ein rohes 20-Byte SHA-1 umgewandelt werden kann, das für den Zugriff auf die Objekt-Datenbank verwendet werden kann. Wenn ja, wird es auf die Standardausgabe ausgegeben, andernfalls wird ein Fehler ausgegeben.

Wenn Sie sicherstellen möchten, dass die Ausgabe tatsächlich ein Objekt in Ihrer Objekt-Datenbank benennt und/oder als bestimmter Objekttyp verwendet werden kann, den Sie benötigen, können Sie den Peel-Operator ^{type} an den Parameter anhängen. Zum Beispiel stellt git rev-parse "$VAR^{commit}" sicher, dass $VAR ein existierendes Objekt benennt, das ein Commit-ish ist (d. h. ein Commit oder ein annotierter Tag, der auf einen Commit verweist). Um sicherzustellen, dass $VAR ein existierendes Objekt eines beliebigen Typs benennt, kann git rev-parse "$VAR^{object}" verwendet werden.

Beachten Sie, dass es ratsam ist, --end-of-options zu verwenden, wenn Sie einen Namen aus einer nicht vertrauenswürdigen Quelle überprüfen, damit das Namensargument nicht mit einer anderen Option verwechselt wird.

-q

--quiet

Nur sinnvoll im Modus --verify. Gibt keine Fehlermeldung aus, wenn das erste Argument kein gültiger Objektname ist; stattdessen wird der Status mit einem Nicht-Null-Wert stillschweigend beendet. SHA-1s für gültige Objektnamen werden bei Erfolg auf stdout ausgegeben.

--sq

Normalerweise wird die Ausgabe zeilenweise für jedes Flag und jeden Parameter gemacht. Diese Option erzeugt eine einzelne Zeile, die für die Verwendung durch die Shell korrekt gequotet ist. Nützlich, wenn Sie erwarten, dass Ihr Parameter Leerzeichen und Zeilenumbrüche enthält (z. B. bei der Verwendung von Pickaxe -S mit git diff-*). Im Gegensatz zur Option --sq-quote wird die Eingabe des Befehls weiterhin wie gewohnt interpretiert.

--short[=<length>]

Wie --verify, kürzt aber den Objektnamen auf ein eindeutiges Präfix mit mindestens <length> Zeichen. Die Mindestlänge beträgt 4, der Standardwert ist der effektive Wert der Konfigurationsvariable core.abbrev (siehe git-config[1]).

--not

Beim Anzeigen von Objektnamen wird ihnen ein ^ vorangestellt und das ^-Präfix von Objektnamen, die bereits eines haben, entfernt.

--abbrev-ref[=(strict|loose)]

Ein nicht eindeutiger kurzer Name des Objektnamens. Die Option core.warnAmbiguousRefs wird verwendet, um den strengen Abkürzungsmodus auszuwählen.

--symbolic

Normalerweise werden die Objektnamen in SHA-1-Form ausgegeben (mit möglichem ^-Präfix); diese Option bewirkt, dass sie in einer Form ausgegeben werden, die dem ursprünglichen Eingabetext so nahe wie möglich kommt.

--symbolic-full-name

Dies ist ähnlich wie --symbolic, aber es ignoriert Eingaben, die keine Refs sind (d. h. Branch- oder Tag-Namen; oder expliziter disambiguierender "heads/master"-Form, wenn Sie den "master"-Branch benennen möchten, wenn es einen unglücklich benannten Tag "master" gibt) und zeigt sie als vollständige Refnamen an (z. B. "refs/heads/master").

--output-object-format=(sha1|sha256|storage)

Ermöglicht die Eingabe von OIDs aus jedem Objektformat, das das aktuelle Repository unterstützt.

Die Angabe "sha1" wird bei Bedarf übersetzt und gibt eine sha1-OID zurück.

Die Angabe "sha256" wird bei Bedarf übersetzt und gibt eine sha256-OID zurück.

Die Angabe "storage" wird bei Bedarf übersetzt und gibt eine OID zurück, die im Speicher-Hash-Algorithmus kodiert ist.

Optionen für Objekte

--all: Zeigt alle in refs/ gefundenen Refs an.
--branches[=<pattern>]
--tags[=<pattern>]
--remotes[=<pattern>]: Zeigt alle Branches, Tags bzw. Remote-Tracking-Branches an (d. h. Refs, die in refs/heads, refs/tags bzw. refs/remotes gefunden werden).

Wenn ein Muster angegeben wird, werden nur Refs angezeigt, die mit dem angegebenen Shell-Glob übereinstimmen. Wenn das Muster kein Globbing-Zeichen (?, * oder [) enthält, wird es durch Anhängen von /* zu einem Präfix-Match.
--glob=<pattern>: Zeigt alle Refs an, die mit dem Shell-Glob-Muster pattern übereinstimmen. Wenn das Muster nicht mit refs/ beginnt, wird dies automatisch vorangestellt. Wenn das Muster kein Globbing-Zeichen (?, * oder [) enthält, wird es durch Anhängen von /* zu einem Präfix-Match.
--exclude=<glob-pattern>: Schließt Refs aus, die dem Muster <glob-pattern> entsprechen und die der nächste --all, --branches, --tags, --remotes oder --glob sonst berücksichtigen würde. Wiederholungen dieser Option häufen Ausschlussmuster an bis zum nächsten --all, --branches, --tags, --remotes oder --glob Option (andere Optionen oder Argumente löschen keine angesammelten Muster).

Die angegebenen Muster dürfen nicht mit refs/heads, refs/tags oder refs/remotes beginnen, wenn sie auf --branches, --tags bzw. --remotes angewendet werden, und sie müssen mit refs/ beginnen, wenn sie auf --glob oder --all angewendet werden. Wenn ein nachgestelltes /* beabsichtigt ist, muss es explizit angegeben werden.
--exclude-hidden=(fetch|receive|uploadpack): Schließt Refs aus, die von git-fetch, git-receive-pack oder git-upload-pack verborgen würden, indem die entsprechenden Konfigurationen fetch.hideRefs, receive.hideRefs oder uploadpack.hideRefs zusammen mit transfer.hideRefs konsultiert werden (siehe git-config[1]). Diese Option beeinflusst die nächste Pseudo-Ref-Option --all oder --glob und wird nach deren Verarbeitung gelöscht.
--disambiguate=<prefix>: Zeigt jedes Objekt an, dessen Name mit dem angegebenen Präfix beginnt. Das <Präfix> muss mindestens 4 hexadezimale Ziffern lang sein, um nicht versehentlich jedes einzelne Objekt im Repository aufzulisten.

Optionen für Dateien

--local-env-vars: Listet die GIT_* Umgebungsvariablen auf, die für das Repository lokal sind (z. B. GIT_DIR oder GIT_WORK_TREE, aber nicht GIT_EDITOR). Nur die Namen der Variablen werden aufgelistet, nicht ihre Werte, auch wenn sie gesetzt sind.
--path-format=(absolute|relative): Steuert das Verhalten bestimmter anderer Optionen. Wenn als absolut angegeben, sind die von diesen Optionen gedruckten Pfade absolut und kanonisch. Wenn als relativ angegeben, sind die Pfade relativ zum aktuellen Arbeitsverzeichnis, wenn dies möglich ist. Der Standard ist Optionsspezifisch.

Diese Option kann mehrmals angegeben werden und wirkt sich nur auf die ihr folgenden Argumente in der Befehlszeile aus, entweder bis zum Ende der Befehlszeile oder bis zur nächsten Instanz dieser Option.

Die folgenden Optionen werden durch --path-format modifiziert

--git-dir: Zeigt $GIT_DIR an, wenn definiert. Andernfalls wird der Pfad zum .git-Verzeichnis angezeigt. Der angezeigte Pfad ist, wenn relativ, relativ zum aktuellen Arbeitsverzeichnis.

Wenn $GIT_DIR nicht definiert ist und das aktuelle Verzeichnis nicht als in einem Git-Repository oder Arbeitsbaum liegend erkannt wird, wird eine Meldung auf stderr ausgegeben und mit einem Nicht-Null-Status beendet.
--git-common-dir: Zeigt $GIT_COMMON_DIR an, wenn definiert, sonst $GIT_DIR.
--resolve-git-dir <path>: Überprüft, ob <path> ein gültiges Repository oder eine gitfile ist, die auf ein gültiges Repository verweist, und gibt den Speicherort des Repositorys aus. Wenn <path> eine gitfile ist, wird der aufgelöste Pfad zum tatsächlichen Repository ausgegeben.
--git-path <path>: Löst "$GIT_DIR/<path>" auf und berücksichtigt andere Pfadumleitvariablen wie $GIT_OBJECT_DIRECTORY, $GIT_INDEX_FILE.... Wenn z. B. $GIT_OBJECT_DIRECTORY auf /foo/bar gesetzt ist, gibt "git rev-parse --git-path objects/abc" /foo/bar/abc zurück.
--show-toplevel: Zeigt den (standardmäßig absoluten) Pfad des obersten Verzeichnisses des Arbeitsbaums an. Wenn kein Arbeitsbaum vorhanden ist, wird ein Fehler gemeldet.
--show-superproject-working-tree: Zeigt den absoluten Pfad der Wurzel des Arbeitsbaums des Superprojekts (falls vorhanden) an, das das aktuelle Repository als sein Submodul verwendet. Gibt nichts aus, wenn das aktuelle Repository nicht als Submodul von einem Projekt verwendet wird.
--shared-index-path: Zeigt den Pfad zur gemeinsamen Indexdatei im Split-Index-Modus an oder gibt eine leere Zeichenfolge aus, wenn nicht im Split-Index-Modus.

Die folgenden Optionen werden von --path-format nicht beeinflusst

--absolute-git-dir: Ähnlich wie --git-dir, aber die Ausgabe ist immer der kanonisierte absolute Pfad.
--is-inside-git-dir: Wenn das aktuelle Arbeitsverzeichnis unterhalb des Repository-Verzeichnisses liegt, wird "true" ausgegeben, andernfalls "false".
--is-inside-work-tree: Wenn das aktuelle Arbeitsverzeichnis innerhalb des Arbeitsbaums des Repositorys liegt, wird "true" ausgegeben, andernfalls "false".
--is-bare-repository: Wenn das Repository ein Bare-Repository ist, wird "true" ausgegeben, andernfalls "false".
--is-shallow-repository: Wenn das Repository flach ist, wird "true" ausgegeben, andernfalls "false".
--show-cdup: Wenn der Befehl aus einem Unterverzeichnis aufgerufen wird, wird der Pfad des obersten Verzeichnisses relativ zum aktuellen Verzeichnis angezeigt (typischerweise eine Sequenz von "../" oder eine leere Zeichenfolge).
--show-prefix: Wenn der Befehl aus einem Unterverzeichnis aufgerufen wird, wird der Pfad des aktuellen Verzeichnisses relativ zum obersten Verzeichnis angezeigt.
--show-object-format[=(storage|input|output|compat)]: Zeigt das Objektformat (Hash-Algorithmus) an, das für das Repository für die Speicherung im .git-Verzeichnis, für die Eingabe, Ausgabe oder Kompatibilität verwendet wird. Für die Eingabe können mehrere Algorithmen ausgegeben werden, durch Leerzeichen getrennt. Wenn compat angefordert wird und kein Kompatibilitätsalgorithmus aktiviert ist, wird eine leere Zeile ausgegeben. Wenn nicht angegeben, ist der Standardwert "storage".
--show-ref-format: Zeigt das Referenzspeicherformat des Repositorys an.

Andere Optionen

--since=<datestring>
--after=<datestring>: Parst den Datumsstring und gibt den entsprechenden --max-age= Parameter für git rev-list aus.
--until=<datestring>
--before=<datestring>: Parst den Datumsstring und gibt den entsprechenden --min-age= Parameter für git rev-list aus.
<arg>…: Zu parsende Flags und Parameter.

REVISIONEN SPEZIFIZIEREN

Ein Revisionsparameter <rev> bezeichnet typischerweise, aber nicht notwendigerweise, ein Commit-Objekt. Er verwendet eine sogenannte erweiterte SHA-1-Syntax. Hier sind verschiedene Möglichkeiten, Objektnamen zu schreiben. Diejenigen, die am Ende dieser Liste aufgeführt sind, bezeichnen Trees und Blobs, die in einem Commit enthalten sind.

Hinweis

Dieses Dokument zeigt die "rohe" Syntax, wie sie von Git gesehen wird. Die Shell und andere UIs erfordern möglicherweise zusätzliche Quoting, um Sonderzeichen zu schützen und Wortaufteilung zu vermeiden.

<sha1>, z. B. dae86e1950b1277e545cee180551750029cfe735, dae86e

Der vollständige SHA-1-Objektname (40-stelliger hexadezimaler String) oder eine führende Teilzeichenfolge, die im Repository eindeutig ist. Z. B. benennen dae86e1950b1277e545cee180551750029cfe735 und dae86e dasselbe Commit-Objekt, wenn kein anderes Objekt in Ihrem Repository mit dem Objekt-Namen dae86e beginnt.

<describeOutput>, z. B. v1.7.4.2-679-g3bee7fb

Ausgabe von git describe; d. h. ein nächstgelegener Tag, optional gefolgt von einem Bindestrich und einer Anzahl von Commits, gefolgt von einem Bindestrich, einem g und einem abgekürzten Objektnamen.

<refname>, z. B. master, heads/master, refs/heads/master

Ein symbolischer Ref-Name. Z. B. bedeutet master typischerweise das Commit-Objekt, auf das von refs/heads/master verwiesen wird. Wenn Sie zufällig sowohl heads/master als auch tags/master haben, können Sie explizit heads/master sagen, um Git mitzuteilen, welches Sie meinen. Bei Mehrdeutigkeit wird ein <refname> durch die erste Übereinstimmung in den folgenden Regeln disambiguiert

Wenn $GIT_DIR/<refname> existiert, ist dies gemeint (dies ist normalerweise nur nützlich für HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD, REBASE_HEAD, REVERT_HEAD, CHERRY_PICK_HEAD, BISECT_HEAD und AUTO_MERGE);
andernfalls refs/<refname>, wenn es existiert;
andernfalls refs/tags/<refname>, wenn es existiert;
andernfalls refs/heads/<refname>, wenn es existiert;
andernfalls refs/remotes/<refname>, wenn es existiert;
andernfalls refs/remotes/<refname>/HEAD, wenn es existiert.

HEAD

bezeichnet den Commit, auf dem Sie die Änderungen im Arbeitsbaum basiert haben.

FETCH_HEAD

zeichnet den Branch auf, den Sie mit Ihrem letzten git fetch-Aufruf aus einem Remote-Repository geholt haben.

ORIG_HEAD

wird von Befehlen erstellt, die Ihren HEAD drastisch bewegen (git am, git merge, git rebase, git reset), um die Position des HEAD vor ihrer Operation aufzuzeichnen, damit Sie die Spitze des Branches leicht auf den Zustand vor der Ausführung zurücksetzen können.

MERGE_HEAD

zeichnet den Commit (die Commits) auf, den (die) Sie in Ihren Branch mergen, wenn Sie git merge ausführen.

REBASE_HEAD

zeichnet während eines Rebase den Commit auf, bei dem die Operation derzeit gestoppt ist, entweder wegen Konflikten oder einem edit-Befehl in einem interaktiven Rebase.

REVERT_HEAD

zeichnet den Commit auf, den Sie revertieren, wenn Sie git revert ausführen.

CHERRY_PICK_HEAD

zeichnet den Commit auf, den Sie cherry-picken, wenn Sie git cherry-pick ausführen.

BISECT_HEAD

zeichnet den aktuellen zu testenden Commit auf, wenn Sie git bisect --no-checkout ausführen.

AUTO_MERGE

zeichnet ein Tree-Objekt, das dem Zustand entspricht, den die ort-Merge-Strategie in den Arbeitsbaum geschrieben hat, als eine Merge-Operation zu Konflikten führte.

Beachten Sie, dass jeder der oben genannten refs/* Fälle entweder aus dem Verzeichnis $GIT_DIR/refs oder aus der Datei $GIT_DIR/packed-refs stammen kann. Während die Codierung des Ref-Namens nicht spezifiziert ist, wird UTF-8 bevorzugt, da einige Ausgabe-Verarbeitung Ref-Namen in UTF-8 annehmen kann.

@

@ allein ist eine Kurzform für HEAD.

[<refname>]@{<date>}, z. B. master@{yesterday}, HEAD@{5 minutes ago}

Ein Ref, gefolgt vom Suffix @ mit einer Datumsangabe in geschweiften Klammern (z. B. {yesterday}, {1 month 2 weeks 3 days 1 hour 1 second ago} oder {1979-02-26 18:30:00}) bezeichnet den Wert des Refs zu einem früheren Zeitpunkt. Dieses Suffix kann nur unmittelbar nach einem Ref-Namen verwendet werden, und der Ref muss ein existierendes Log haben ($GIT_DIR/logs/<ref>). Beachten Sie, dass dies den Zustand Ihres **lokalen** Refs zu einem bestimmten Zeitpunkt nachschlägt; z. B. was letzte Woche in Ihrem lokalen master-Branch war. Wenn Sie Commits aus bestimmten Zeiten betrachten möchten, siehe --since und --until.

<refname>@{<n>}, z. B. master@{1}

Ein Ref, gefolgt vom Suffix @ mit einer Ordnungsangabe in geschweiften Klammern (z. B. {1}, {15}) bezeichnet den n-ten vorherigen Wert dieses Refs. Zum Beispiel ist master@{1} der unmittelbar vorherige Wert von master, während master@{5} der 5. vorherige Wert von master ist. Dieses Suffix kann nur unmittelbar nach einem Ref-Namen verwendet werden, und der Ref muss ein existierendes Log haben ($GIT_DIR/logs/<refname>).

@{<n>}, z. B. @{1}

Sie können die @-Konstruktion mit einem leeren Ref-Teil verwenden, um auf einen Reflog-Eintrag des aktuellen Branches zuzugreifen. Wenn Sie sich zum Beispiel im Branch blabla befinden, bedeutet @{1} dasselbe wie blabla@{1}.

@{-<n>}, z. B. @{-1}

Die Konstruktion @{-<n>} bezeichnet den <n>-ten zuvor ausgecheckten Branch/Commit vor dem aktuellen.

[<branchname>]@{upstream}, z. B. master@{upstream}, @{u}

Ein Branch B kann so konfiguriert sein, dass er auf einem Branch X (konfiguriert mit branch.<name>.merge) bei einem Remote R (konfiguriert mit branch.<name>.remote) aufbaut. B@{u} bezieht sich auf den Remote-Tracking-Branch für den Branch X von Remote R, der typischerweise unter refs/remotes/R/X zu finden ist.

[<branchname>]@{push}, z. B. master@{push}, @{push}

Das Suffix @{push} meldet den Branch, "wohin wir pushen würden", wenn git push ausgeführt würde, während branchname ausgecheckt war (oder der aktuelle HEAD, wenn kein branchname angegeben ist). Wie bei @{upstream} melden wir den Remote-Tracking-Branch, der diesem Branch am Remote entspricht.

Hier ist ein Beispiel zur Verdeutlichung

$ git config push.default current
$ git config remote.pushdefault myfork
$ git switch -c mybranch origin/master

$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/master

$ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch

Beachten Sie im Beispiel, dass wir einen dreieckigen Workflow eingerichtet haben, bei dem wir von einem Ort ziehen und zu einem anderen pushen. In einem nicht-dreieckigen Workflow ist @{push} dasselbe wie @{upstream}, und es wird dafür nicht benötigt.

Dieses Suffix wird auch in Großbuchstaben akzeptiert und bedeutet unabhängig von der Groß-/Kleinschreibung dasselbe.

<rev>^[<n>], z. B. HEAD^, v1.5.1^0

Ein Suffix ^ zu einem Revisionsparameter bedeutet den ersten Elternteil dieses Commit-Objekts. ^<n> bedeutet den <n>-ten Elternteil (d. h. <rev>^ ist äquivalent zu <rev>^1). Als Sonderregel bedeutet <rev>^0 den Commit selbst und wird verwendet, wenn <rev> der Objektname eines Tag-Objekts ist, das auf ein Commit-Objekt verweist.

<rev>~[<n>], z. B. HEAD~, master~3

Ein Suffix ~ zu einem Revisionsparameter bedeutet den ersten Elternteil dieses Commit-Objekts. Ein Suffix ~<n> zu einem Revisionsparameter bedeutet das Commit-Objekt, das der <n>-te Generationen-Vorfahre des benannten Commit-Objekts ist, indem nur den ersten Elternteilen gefolgt wird. D. h. <rev>~3 ist äquivalent zu <rev>^^^, was wiederum äquivalent zu <rev>^1^1^1 ist. Sehen Sie unten eine Illustration der Verwendung dieser Form.

<rev>^{<type>}, z. B. v0.99.8^{commit}

Ein Suffix ^ gefolgt von einem Objekttypnamen in geschweiften Klammern bedeutet, dass das Objekt bei <rev> rekursiv dereferenziert wird, bis ein Objekt vom Typ <type> gefunden wird oder das Objekt nicht mehr dereferenziert werden kann (in diesem Fall Fehler). Zum Beispiel, wenn <rev> ein Commit-ish ist, beschreibt <rev>^{commit} das entsprechende Commit-Objekt. Ebenso, wenn <rev> ein Tree-ish ist, beschreibt <rev>^{tree} das entsprechende Tree-Objekt. <rev>^0 ist eine Kurzform für <rev>^{commit}.

<rev>^{object} kann verwendet werden, um sicherzustellen, dass <rev> ein existierendes Objekt benennt, ohne zu verlangen, dass <rev> ein Tag ist, und ohne <rev> zu dereferenzieren; da ein Tag bereits ein Objekt ist, muss er nicht einmal dereferenziert werden, um zu einem Objekt zu gelangen.

<rev>^{tag} kann verwendet werden, um sicherzustellen, dass <rev> ein existierendes Tag-Objekt identifiziert.

<rev>^{}, z. B. v0.99.8^{}

Ein Suffix ^ gefolgt von einem leeren Klammernpaar bedeutet, dass das Objekt ein Tag sein könnte, und dereferenziert den Tag rekursiv, bis ein Nicht-Tag-Objekt gefunden wird.

<rev>^{/<text>}, z. B. HEAD^{/fix nasty bug}

Ein Suffix ^ zu einem Revisionsparameter, gefolgt von einem Klammernpaar, das einen Text mit einem vorangestellten Schrägstrich enthält, ist dasselbe wie die unten stehende Syntax :/fix nasty bug, mit dem Unterschied, dass er den jüngsten passenden Commit zurückgibt, der von <rev> vor dem ^ erreichbar ist.

:/<text>, z. B. :/fix nasty bug

Ein Doppelpunkt, gefolgt von einem Schrägstrich, gefolgt von einem Text, bezeichnet einen Commit, dessen Commit-Nachricht dem angegebenen regulären Ausdruck entspricht. Dieser Name gibt den jüngsten passenden Commit zurück, der von jedem Ref, einschließlich HEAD, erreichbar ist. Der reguläre Ausdruck kann jeden Teil der Commit-Nachricht abgleichen. Um Nachrichten abzugleichen, die mit einer Zeichenfolge beginnen, kann z. B. :/^foo verwendet werden. Die spezielle Sequenz :/! ist für Modifikatoren dessen reserviert, was abgeglichen wird. :/!-foo führt einen negativen Abgleich durch, während :/!!foo ein literales ! gefolgt von foo abgleicht. Jede andere Sequenz, die mit :/! beginnt, ist derzeit reserviert. Abhängig vom angegebenen Text können die Wortaufteilungsregeln der Shell zusätzliches Quoting erfordern.

<rev>:<path>, z. B. HEAD:README, master:./README

Ein Suffix : gefolgt von einem Pfad bezeichnet den Blob oder Tree am angegebenen Pfad im Tree-ish-Objekt, das durch den Teil vor dem Doppelpunkt benannt ist. Ein Pfad, der mit ./ oder ../ beginnt, ist relativ zum aktuellen Arbeitsverzeichnis. Der angegebene Pfad wird in einen Pfad relativ zum Stammverzeichnis des Arbeitsbaums konvertiert. Dies ist am nützlichsten, um einen Blob oder Tree aus einem Commit oder Tree anzusprechen, der dieselbe Baumstruktur wie der Arbeitsbaum aufweist.

:[<n>:]<path>, z. B. :0:README, :README

Ein Doppelpunkt, optional gefolgt von einer Stufennummer (0 bis 3) und einem Doppelpunkt, gefolgt von einem Pfad, bezeichnet einen Blob im Index am angegebenen Pfad. Eine fehlende Stufennummer (und der folgende Doppelpunkt) bezeichnet einen Eintrag der Stufe 0. Während eines Merges ist Stufe 1 der gemeinsame Vorfahre, Stufe 2 ist die Version des Zielbranches (typischerweise der aktuelle Branch), und Stufe 3 ist die Version des Branches, der gemergt wird.

Hier ist eine Illustration von Jon Loeliger. Sowohl die Commit-Knoten B als auch C sind Eltern von Commit-Knoten A. Eltern-Commits sind von links nach rechts geordnet.

G   H   I   J
 \ /     \ /
  D   E   F
   \  |  / \
    \ | /   |
     \|/    |
      B     C
       \   /
        \ /
         A

A =      = A^0
B = A^   = A^1     = A~1
C =      = A^2
D = A^^  = A^1^1   = A~2
E = B^2  = A^^2
F = B^3  = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2  = B^^2    = A^^^2  = A~2^2
I = F^   = B^3^    = A^^3^
J = F^2  = B^3^2   = A^^3^2

BEREICHE ANGEBEN

Befehle zur Traversierung der Historie wie git log arbeiten mit einer Menge von Commits, nicht nur mit einem einzelnen Commit.

Für diese Befehle bedeutet die Angabe einer einzelnen Revision, unter Verwendung der im vorherigen Abschnitt beschriebenen Notation, die Menge der Commits, die von dem angegebenen Commit erreichbar sind.

Die Angabe mehrerer Revisionen bedeutet die Menge der Commits, die von einem der angegebenen Commits erreichbar sind.

Die erreichbare Menge eines Commits ist der Commit selbst und die Commits in seiner Abstammungskette.

Es gibt mehrere Notationen, um eine Menge verbundener Commits (ein "Revisionsbereich") anzugeben, die unten illustriert sind.

Commit-Ausschlüsse

^<rev> (Caret) Notation: Um von einem Commit erreichbare Commits auszuschließen, wird eine Präfix-^-Notation verwendet. Z. B. bedeutet ^r1 r2 Commits, die von r2 erreichbar sind, aber die von r1 erreichbaren ausschließen (d. h. r1 und seine Vorfahren).

Gepunktete Bereichsnotationen

Die .. (Zwei-Punkt-)Bereichsnotation: Die Mengenoperation ^r1 r2 kommt so oft vor, dass es dafür eine Kurzform gibt. Wenn Sie zwei Commits r1 und r2 haben (benannt nach der unter REVISIONEN SPEZIFIZIEREN erklärten Syntax), können Sie Commits, die von r2 erreichbar sind und solche ausschließen, die von r1 erreichbar sind, mit ^r1 r2 anfordern, und es kann als r1..r2 geschrieben werden.
Die ... (Drei-Punkt-)Symmetrische-Differenz-Notation: Eine ähnliche Notation r1...r2 wird als symmetrische Differenz von r1 und r2 bezeichnet und ist definiert als r1 r2 --not $(git merge-base --all r1 r2). Sie ist die Menge von Commits, die von entweder r1 (linke Seite) oder r2 (rechte Seite) erreichbar sind, aber nicht von beiden.

In diesen beiden Kurzschreibweisen können Sie ein Ende weglassen und es auf HEAD setzen lassen. Zum Beispiel ist origin.. eine Kurzschreibweise für origin..HEAD und fragt "Was habe ich getan, seit ich vom origin-Branch abgezweigt bin?". Ähnlich ist ..origin eine Kurzschreibweise für HEAD..origin und fragt "Was hat der origin getan, seit ich von ihnen abgezweigt bin?". Beachten Sie, dass .. gleichbedeutend mit HEAD..HEAD ist, was ein leerer Bereich ist, der sowohl von HEAD erreichbar als auch unerreichbar ist.

Befehle, die speziell für zwei unterschiedliche Bereiche ausgelegt sind (z. B. "git range-diff R1 R2" zum Vergleichen zweier Bereiche), existieren zwar, sind aber Ausnahmen. Sofern nicht anders angegeben, arbeiten alle "git"-Befehle, die auf einer Menge von Commits arbeiten, mit einem einzelnen Revisionsbereich. Mit anderen Worten, das Nebeneinanderstellen zweier "Zwei-Punkte-Bereichsnotationen", z. B.

$ git log A..B C..D

spezifiziert für die meisten Befehle nicht zwei Revisionsbereiche. Stattdessen wird eine einzelne zusammenhängende Menge von Commits benannt, d. h. diejenigen, die von B oder D erreichbar sind, aber weder von A noch von C. In einer linearen Historie wie dieser

---A---B---o---o---C---D

weil A und B von C erreichbar sind, ist der durch diese beiden Punktbereiche angegebene Revisionsbereich ein einzelner Commit D.

Andere <rev>^ Eltern-Kurzschreibweisen

Es existieren drei weitere Kurzschreibweisen, die sich besonders für Merge-Commits eignen, um eine Menge zu benennen, die aus einem Commit und seinen Eltern-Commits gebildet wird.

Die Notation r1^@ bedeutet alle Eltern von r1.

Die Notation r1^! schließt den Commit r1 ein, aber schließt alle seine Eltern aus. Für sich allein steht diese Notation für den einzelnen Commit r1.

Die Notation <rev>^-[<n>] schließt <rev> ein, schließt aber den <n>-ten Elternteil aus (d. h. eine Kurzschreibweise für <rev>^<n>..<rev>), wobei <n> = 1 ist, wenn nicht angegeben. Dies ist typischerweise nützlich für Merge-Commits, bei denen Sie einfach <commit>^- übergeben können, um alle Commits im Branch zu erhalten, der in den Merge-Commit <commit> gemerged wurde (einschließlich <commit> selbst).

Während <rev>^<n> sich auf die Angabe eines einzelnen Eltern-Commits bezog, berücksichtigen diese drei Notationen auch dessen Eltern. Sie können zum Beispiel HEAD^2^@ sagen, aber Sie können nicht HEAD^@^2 sagen.

Zusammenfassung der Revisionsbereiche

<rev>: Schließt Commits ein, die von <rev> erreichbar sind (d. h. <rev> und seine Vorfahren).
^<rev>: Schließt Commits aus, die von <rev> erreichbar sind (d. h. <rev> und seine Vorfahren).
<rev1>..<rev2>: Schließt Commits ein, die von <rev2> erreichbar sind, schließt aber diejenigen aus, die von <rev1> erreichbar sind. Wenn <rev1> oder <rev2> weggelassen wird, wird standardmäßig HEAD verwendet.
<rev1>...<rev2>: Schließt Commits ein, die entweder von <rev1> oder <rev2> erreichbar sind, schließt aber diejenigen aus, die von beiden erreichbar sind. Wenn entweder <rev1> oder <rev2> weggelassen wird, wird standardmäßig HEAD verwendet.
<rev>^@, z. B. HEAD^@: Ein Suffix ^ gefolgt von einem At-Zeichen ist gleichbedeutend mit dem Auflisten aller Eltern von <rev> (d. h. schließt alles ein, was von seinen Eltern erreichbar ist, aber nicht den Commit selbst).
<rev>^!, z. B. HEAD^!: Ein Suffix ^ gefolgt von einem Ausrufezeichen ist gleichbedeutend mit der Angabe des Commits <rev> und all seiner Eltern, die mit ^ vorangestellt sind, um sie (und ihre Vorfahren) auszuschließen.
<rev>^-<n>, z. B. HEAD^-, HEAD^-2: Entspricht <rev>^<n>..<rev>, wobei <n> = 1 ist, wenn nicht angegeben.

Hier ist eine Handvoll Beispiele, die die obige Loeliger-Illustration verwenden, wobei jeder Schritt bei der Erweiterung und Auswahl der Notation sorgfältig erläutert wird

   Args   Expanded arguments    Selected commits
   D                            G H D
   D F                          G H I J D F
   ^G D                         H D
   ^D B                         E I J F B
   ^D B C                       E I J F B C
   C                            I J F C
   B..C   = ^B C                C
   B...C  = B ^F C              G H D E B C
   B^-    = B^..B
	  = ^B^1 B              E I J F B
   C^@    = C^1
	  = F                   I J F
   B^@    = B^1 B^2 B^3
	  = D E F               D G H E F I J
   C^!    = C ^C^@
	  = C ^C^1
	  = C ^F                C
   B^!    = B ^B^@
	  = B ^B^1 ^B^2 ^B^3
	  = B ^D ^E ^F          B
   F^! D  = F ^I ^J D           G H D F

PARSEOPT

Im Modus --parseopt hilft git rev-parse bei der Massierung von Optionen, um Shell-Skripten die gleichen Einrichtungen wie C-Builtins zur Verfügung zu stellen. Es fungiert als Optionsnormalisierer (z. B. teilt es einzelne Schalter auf und aggregiert Werte), ähnlich wie getopt(1).

Es nimmt die Spezifikation der zu parsierenden und zu verstehenden Optionen auf der Standardeingabe entgegen und gibt auf der Standardausgabe eine Zeichenkette aus, die für die Verwendung mit sh(1) eval geeignet ist, um die Argumente durch normalisierte zu ersetzen. Im Fehlerfall gibt es die Nutzungsmeldung auf dem Standardfehlerausgabe-Stream aus und beendet sich mit dem Code 129.

Hinweis: Stellen Sie sicher, dass Sie das Ergebnis quotieren, wenn Sie es an eval übergeben. Ein Beispiel finden Sie unten.

Eingabeformat

Das Eingabeformat von git rev-parse --parseopt ist vollständig textbasiert. Es besteht aus zwei Teilen, getrennt durch eine Zeile, die nur -- enthält. Die Zeilen vor dem Trennzeichen (sollten eine oder mehrere sein) werden für die Nutzungsmeldung verwendet. Die Zeilen danach beschreiben die Optionen.

Jede Zeile mit Optionen hat dieses Format

<opt-spec><flags>*<arg-hint>? SP+ help LF

<opt-spec>

Sein Format ist das Kurzoptionszeichen, dann der Langoptionsname, getrennt durch ein Komma. Beide Teile sind nicht zwingend erforderlich, obwohl mindestens einer notwendig ist. Darf keine der <flags>-Zeichen enthalten. h,help, dry-run und f sind Beispiele für korrekte <opt-spec>.

<flags>

<flags> sind *, =, ? oder !.

Verwenden Sie =, wenn die Option ein Argument erfordert.
Verwenden Sie ?, um anzugeben, dass die Option ein optionales Argument erfordert. Sie möchten wahrscheinlich den Modus --stuck-long verwenden, um das optionale Argument eindeutig parsen zu können.
Verwenden Sie *, um anzugeben, dass diese Option nicht in der Nutzungsmeldung aufgeführt werden soll, die für das Argument -h generiert wird. Sie wird für --help-all angezeigt, wie in gitcli[7] beschrieben.
Verwenden Sie !, um die entsprechende negierte Langoption nicht verfügbar zu machen.

<arg-hint>

<arg-hint> wird, falls angegeben, als Name des Arguments in der Hilfeausgabe für Optionen verwendet, die Argumente benötigen. <arg-hint> wird durch das erste Leerzeichen beendet. Es ist üblich, einen Bindestrich zu verwenden, um Wörter in einem mehrteiligen Argumenthinweis zu trennen.

Der Rest der Zeile, nach Entfernung der Leerzeichen, wird als Hilfe für die Option verwendet.

Leere Zeilen werden ignoriert, und Zeilen, die dieser Spezifikation nicht entsprechen, werden als Optionsgruppenüberschriften verwendet (beginnen Sie die Zeile mit einem Leerzeichen, um solche Zeilen absichtlich zu erstellen).

Beispiel

OPTS_SPEC="\
some-command [<options>] <args>...

some-command does foo and bar!
--
h,help!   show the help

foo       some nifty option --foo
bar=      some cool option --bar with an argument
baz=arg   another cool option --baz with a named argument
qux?path  qux may take a path argument but has meaning by itself

  An option group Header
C?        option C with an optional argument"

eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"

Nutzungstext

Wenn "$@" im obigen Beispiel -h oder --help ist, wird der folgende Nutzungstext angezeigt

usage: some-command [<options>] <args>...

    some-command does foo and bar!

    -h, --help            show the help
    --[no-]foo            some nifty option --foo
    --[no-]bar ...        some cool option --bar with an argument
    --[no-]baz <arg>      another cool option --baz with a named argument
    --[no-]qux[=<path>]   qux may take a path argument but has meaning by itself

An option group Header
    -C[...]               option C with an optional argument

SQ-QUOTE

Im Modus --sq-quote gibt git rev-parse auf der Standardausgabe eine einzelne Zeile aus, die für sh(1) eval geeignet ist. Diese Zeile wird durch Normalisierung der Argumente nach --sq-quote gebildet. Es wird nichts anderes getan, als die Argumente zu quotieren.

Wenn Sie möchten, dass die Eingabe des Befehls vor der Ausgabe von Shell-Zitaten weiterhin wie gewohnt von git rev-parse interpretiert wird, siehe die Option --sq.

Beispiel

$ cat >your-git-script.sh <<\EOF
#!/bin/sh
args=$(git rev-parse --sq-quote "$@")   # quote user-supplied arguments
command="git frotz -n24 $args"          # and use it inside a handcrafted
					# command line
eval "$command"
EOF

$ sh your-git-script.sh "a b'c"

BEISPIELE

Gibt den Objektname des aktuellen Commits aus
```
$ git rev-parse --verify HEAD
```
Gibt den Commit-Objektnamen aus der Revision in der Shell-Variable $REV aus
```
$ git rev-parse --verify --end-of-options $REV^{commit}
```
Dies führt zu einem Fehler, wenn $REV leer ist oder keine gültige Revision.
Ähnlich wie oben
```
$ git rev-parse --default master --verify --end-of-options $REV
```
aber wenn $REV leer ist, wird der Commit-Objektname von master ausgegeben.

Teil der git[1] Suite

Einrichtung und Konfiguration

Projekte holen und erstellen

Grundlegende Snapshots

Branching und Merging

Projekte teilen und aktualisieren

Inspektion und Vergleich

Patching

Debugging

E-Mail

Externe Systeme

Server-Administration

Anleitungen

Administration

Plumbing-Befehle

NAME

SYNOPSIS

BESCHREIBUNG

OPTIONEN

Betriebsmodi

Optionen für --parseopt

Optionen für Filterung

Optionen für die Ausgabe

Optionen für Objekte

Optionen für Dateien

Andere Optionen

REVISIONEN SPEZIFIZIEREN

BEREICHE ANGEBEN

Commit-Ausschlüsse

Gepunktete Bereichsnotationen

Andere <rev>^ Eltern-Kurzschreibweisen

Zusammenfassung der Revisionsbereiche

PARSEOPT

Eingabeformat

Beispiel

Nutzungstext

SQ-QUOTE

Beispiel

BEISPIELE

GIT

rev-parse