git-rev-parse – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

git-rev-parse – Parameter auswählen und massieren

ZUSAMMENFASSUNG

git rev-parse [ --Möglichkeit ] ...

BESCHREIBUNG

Viele Git-Porzellan-Befehle erfordern eine Mischung aus Flags (d. h. Parameter, die mit a beginnen
Strich -) und Parameter, die für den Basiswert bestimmt sind git Drehzahlliste Befehl, den sie intern verwenden
und Flags und Parameter für die anderen Befehle, die sie nachgeschaltet verwenden git Drehzahlliste. Dies
Der Befehl wird verwendet, um zwischen ihnen zu unterscheiden.

OPTIONAL

Produktion Modi
Jede dieser Optionen muss zuerst in der Befehlszeile erscheinen.

--parseopt
Verwenden Sie die git rev-parse im Optionsparsing-Modus (siehe Abschnitt PARSEOPT unten).

--sq-quote
Verwenden Sie die git rev-parse im Shell-Quoting-Modus (siehe Abschnitt SQ-QUOTE weiter unten). Im Kontrast zu
Mit der Option --sq unten führt dieser Modus nur Anführungszeichen aus. Es wird nichts anderes getan, um zu befehlen
Eingang.

Optionen für --parseopt
--keep-dashdash
Nur im --parseopt-Modus sinnvoll. Weist den Optionsparser an, das erste Echo auszugeben –
getroffen, anstatt es zu überspringen.

--stop-at-non-option
Nur im --parseopt-Modus sinnvoll. Lässt den Optionsparser beim ersten Mal stoppen
Nicht-Optionsargument. Dies kann zum Parsen von Unterbefehlen verwendet werden, die Optionen annehmen
sich.

--stuck-long
Nur im --parseopt-Modus sinnvoll. Geben Sie die Optionen in ihrer Langform aus, wenn
verfügbar, und ihre Argumente stecken fest.

Optionen für Filterung
--revs-only
Geben Sie keine Flags und Parameter aus, für die Sie nicht gedacht sind git Drehzahlliste Befehl.

--no-revs
Geben Sie keine Flags und Parameter aus, für die gedacht ist git Drehzahlliste Befehl.

--Flaggen
Geben Sie keine Nicht-Flag-Parameter aus.

--no-flags
Flag-Parameter werden nicht ausgegeben.

Optionen für Output
--Standard
Wenn vom Benutzer kein Parameter angegeben ist, verwenden Sie stattdessen.

--Präfix
Verhalten Sie sich so, als ob git rev-parse wurde von der aufgerufen Unterverzeichnis der Arbeitsdatei
Baum. Alle relativen Dateinamen werden so aufgelöst, als ob ihnen ein Präfix vorangestellt wäre und wird sein
in dieser Form gedruckt.

Dies kann verwendet werden, um Argumente in einen Befehl umzuwandeln, der in einem Unterverzeichnis ausgeführt wird, sodass sie
kann auch nach dem Verschieben auf die oberste Ebene des Repositorys weiterhin verwendet werden. Zum Beispiel:

prefix=$(git rev-parse --show-prefix)
cd „$(git rev-parse --show-toplevel)“
eval „set -- $(git rev-parse --sq --prefix „$prefix“ „$@“)“

--verifizieren
Stellen Sie sicher, dass genau ein Parameter bereitgestellt wird und dass dieser in einen Rohwert umgewandelt werden kann
20-Byte-SHA-1, mit dem auf die Objektdatenbank zugegriffen werden kann. Wenn ja, senden Sie es an die
Standardausgabe; andernfalls wird ein Fehler ausgegeben.

Wenn Sie sicherstellen möchten, dass die Ausgabe tatsächlich ein Objekt in Ihrem Objekt benennt
Datenbank und/oder als spezifischer Objekttyp verwendet werden kann, den Sie benötigen, können Sie das hinzufügen
^{type}-Peeling-Operator für den Parameter. Beispiel: git rev-parse „$VAR^{commit}“
stellt sicher, dass $VAR ein vorhandenes Objekt benennt, das ein Commit ist (d. h. ein Commit oder).
ein mit Anmerkungen versehenes Tag, das auf einen Commit verweist). Um sicherzustellen, dass $VAR ein vorhandenes benennt
Objekt eines beliebigen Typs, git rev-parse „$VAR^{object}“ kann verwendet werden.

-q, --leise
Nur im --verify-Modus sinnvoll. Geben Sie beim ersten Argument keine Fehlermeldung aus
ist kein gültiger Objektname; Beenden Sie stattdessen stillschweigend mit einem Status ungleich Null. SHA-1s für
Gültige Objektnamen werden bei Erfolg auf stdout ausgegeben.

--Quadratmeter
Normalerweise erfolgt die Ausgabe in einer Zeile pro Flag und Parameter. Diese Option macht die Ausgabe a
einzelne Zeile, ordnungsgemäß für den Verbrauch durch Shell angegeben. Nützlich, wenn Sie Ihre erwarten
Parameter, der Leerzeichen und Zeilenumbrüche enthält (z. B. bei Verwendung von pickaxe -S mit git
diff-*). Im Gegensatz zur Option --sq-quote wird die Befehlseingabe weiterhin interpretiert
wie üblich.

--nicht
Wenn Sie Objektnamen anzeigen, stellen Sie ihnen das Präfix voran ^ und ausziehen ^ Präfix aus den Objektnamen
die schon einen haben.

--abbrev-ref[=(strict|loose)]
Ein eindeutiger Kurzname des Objektnamens. Die Option core.warnAmbiguousRefs ist
Wird verwendet, um den strengen Abkürzungsmodus auszuwählen.

--short, --short=Nummer
Anstatt die vollständigen SHA-1-Werte von Objektnamen auszugeben, versuchen Sie, diese abzukürzen
ein kürzerer eindeutiger Name. Wenn keine Länge angegeben ist, wird 7 verwendet. Die Mindestlänge beträgt 4.

--symbolisch
Normalerweise werden die Objektnamen im SHA-1-Format ausgegeben (mit evtl ^ Präfix); Das
Mit dieser Option werden sie in einer Form ausgegeben, die der ursprünglichen Eingabe so nahe wie möglich kommt.

--symbolic-vollständiger-Name
Dies ähnelt --symbolic, lässt jedoch Eingaben weg, die keine Refs sind (z. B. Zweig oder).
Tag-Namen; oder expliziter die eindeutige Form „Köpfe/Master“, wenn Sie möchten
Benennen Sie den „Master“-Zweig, wenn ein Tag mit dem unglücklichen Namen „Master“ vorhanden ist, und zeigen Sie ihn an
sie als vollständige Referenznamen (z. B. „refs/heads/master“).

Optionen für Objekte
--alle
Alle in refs/ gefundenen Refs anzeigen.

--branches[=Muster], --tags[=Muster], --remotes[=Muster]
Alle Zweige, Tags bzw. Remote-Tracking-Zweige anzeigen (d. h. gefundene Referenzen).
in refs/heads, refs/tags bzw. refs/remotes).

Wenn ein Muster angegeben ist, werden nur Refs angezeigt, die mit dem angegebenen Shell-Glob übereinstimmen. Wenn die
Wenn das Muster kein Globbing-Zeichen (?, * oder [) enthält, wird es in ein Präfix umgewandelt
Übereinstimmung durch Anhängen von /*.

--glob=Muster
Zeigt alle Refs an, die zum Muster des Shell-Glob-Musters passen. Wenn das Muster nicht startet
Bei refs/ wird dies automatisch vorangestellt. Wenn das Muster kein a enthält
Wenn Sie ein Globbing-Zeichen (?, * oder [) verwenden, wird es durch Anhängen von /* in eine Präfixübereinstimmung umgewandelt.

--exclude=
Schließen Sie keine Refs-Übereinstimmungen ein dass die nächsten --all, --branches, --tags,
--remotes oder --glob würden andernfalls in Betracht ziehen. Wiederholungen dieser Option häufen sich
Ausschlussmuster bis zum nächsten --all, --branches, --tags, --remotes oder --glob
Option (andere Optionen oder Argumente löschen keine angesammelten Muster).

Die angegebenen Muster sollten nicht mit refs/heads, refs/tags oder refs/remotes beginnen, wenn
werden auf --branches, --tags bzw. --remotes angewendet und müssen mit beginnen
refs/ bei Anwendung auf --glob oder --all. Wenn ein Trailing /* beabsichtigt ist, muss es gegeben sein
ausdrücklich.

--disambiguate=
Zeigt jedes Objekt an, dessen Name mit dem angegebenen Präfix beginnt. Der muss dabei sein
Mindestens 4 hexadezimale Ziffern lang, um zu vermeiden, dass jedes einzelne Objekt im aufgeführt wird
versehentlich in das Repository verschoben.

Optionen für Mappen
--local-env-vars
Listen Sie die GIT_*-Umgebungsvariablen auf, die lokal im Repository sind (z. B. GIT_DIR oder
GIT_WORK_TREE, aber nicht GIT_EDITOR). Es werden nur die Namen der Variablen aufgeführt, nicht
ihren Wert, auch wenn sie festgelegt sind.

--git-dir
$GIT_DIR anzeigen, falls definiert. Andernfalls zeigen Sie den Pfad zum .git-Verzeichnis an. Der Weg
Wenn relativ angezeigt, ist es relativ zum aktuellen Arbeitsverzeichnis.

Wenn $GIT_DIR nicht definiert ist und das aktuelle Verzeichnis nicht in einem Git liegt
Das Repository oder der Arbeitsbaum geben eine Nachricht an stderr aus und werden mit einem Status ungleich Null beendet.

--git-common-dir
Zeigt $GIT_COMMON_DIR an, falls definiert, andernfalls $GIT_DIR.

--is-inside-git-dir
Wenn das aktuelle Arbeitsverzeichnis unterhalb des Repository-Verzeichnisses liegt, geben Sie „true“ aus.
andernfalls „falsch“.

--is-inside-work-tree
Wenn sich das aktuelle Arbeitsverzeichnis im Arbeitsbaum des Repositorys befindet, wird gedruckt
„wahr“, andernfalls „falsch“.

--is-bare-repository
Wenn das Repository leer ist, geben Sie „true“ aus, andernfalls „false“.

--resolve-git-dir
Überprüfen Sie, ob ist ein gültiges Repository oder eine Git-Datei, die auf ein gültiges Repository verweist,
und drucken Sie den Speicherort des Repositorys aus. Wenn ist eine Git-Datei, dann wird sie aufgelöst
Der Pfad zum eigentlichen Repository wird gedruckt.

--git-path
„$GIT_DIR/“ auflösen " und nimmt andere Pfadverschiebungsvariablen an, wie z
$GIT_OBJECT_DIRECTORY, $GIT_INDEX_FILE... berücksichtigt. Zum Beispiel, wenn
$GIT_OBJECT_DIRECTORY wird auf /foo/bar und dann auf „git rev-parse --git-path Objects/abc“ gesetzt.
gibt /foo/bar/abc zurück.

--show-cdup
Wenn der Befehl aus einem Unterverzeichnis aufgerufen wird, zeigen Sie den Pfad der obersten Ebene an
Verzeichnis relativ zum aktuellen Verzeichnis (normalerweise eine Folge von „../“ oder eine
leerer String).

--show-präfix
Wenn der Befehl aus einem Unterverzeichnis aufgerufen wird, zeigen Sie den Pfad des aktuellen an
Verzeichnis relativ zum Verzeichnis der obersten Ebene.

--show-toplevel
Zeigt den absoluten Pfad des Verzeichnisses der obersten Ebene an.

--shared-index-path
Zeigt den Pfad zur freigegebenen Indexdatei im Split-Index-Modus an oder leer, wenn nicht
Split-Index-Modus.

Andere Optionen
--since=Datumszeichenfolge, --after=Datumszeichenfolge
Analysieren Sie die Datumszeichenfolge und geben Sie den entsprechenden Parameter --max-age= aus git
Drehzahlliste.

--until=Datumszeichenfolge, --before=Datumszeichenfolge
Analysieren Sie die Datumszeichenfolge und geben Sie den entsprechenden Parameter --min-age= aus git
Drehzahlliste.

...
Zu analysierende Flags und Parameter.

SPEZIFIKATION REVISIONEN

Ein Revisionsparameter benennt normalerweise, aber nicht unbedingt, ein Commit-Objekt. Es benutzt
was heißt ein verlängert SHA-1 Syntax. Es gibt verschiedene Möglichkeiten, Objektnamen zu buchstabieren. Der
Die am Ende dieser Liste aufgeführten Namen benennen Bäume und Blobs, die in einem Commit enthalten sind.

, z.B dae86e1950b1277e545cee180551750029cfe735, dae86e
Der vollständige SHA-1-Objektname (40-Byte-Hexadezimalzeichenfolge) oder eine führende Teilzeichenfolge
ist innerhalb des Repositorys eindeutig. ZB dae86e1950b1277e545cee180551750029cfe735 und
dae86e benennen beide dasselbe Commit-Objekt, wenn sich in Ihrem Repository kein anderes Objekt befindet
dessen Objektname mit dae86e beginnt.

, z.B v1.7.4.2-679-g3bee7fb
Ausgabe von Git Describe; dh ein nächstgelegenes Tag, optional gefolgt von einem Bindestrich und einem
Anzahl der Commits, gefolgt von einem Bindestrich, a gund einen abgekürzten Objektnamen.

, z.B Master, Leiter/Meister, Refs/Heads/Master
Ein symbolischer Referenzname. Z.B Master bedeutet normalerweise das Commit-Objekt, auf das verwiesen wird
Refs/Heads/Master. Wenn Sie zufällig beides haben Leiter/Meister und Tags/Master, es können
explizit sagen Leiter/Meister um Git zu sagen, welches du meinst. Bei Mehrdeutigkeit a
wird durch die erste Übereinstimmung in den folgenden Regeln eindeutig gemacht:

1. Wenn $GIT_DIR/ existiert, das meinen Sie (das ist normalerweise nur nützlich).
für KOPF, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD und CHERRY_PICK_HEAD);

2. ansonsten, refs/ wenn es existiert;

3. ansonsten, refs/tags/ wenn es existiert;

4. ansonsten, refs/heads/ wenn es existiert;

5. ansonsten, refs/remotes/ wenn es existiert;

6. ansonsten, refs/remotes/ /KOPF wenn es existiert.

KOPF benennt den Commit, auf dem Sie die Änderungen im Arbeitsbaum basieren.
FETCH_HEAD zeichnet den Zweig auf, den Sie mit Ihrem aus einem Remote-Repository abgerufen haben
Letzter Git-Fetch-Aufruf. ORIG_HEAD wird durch Befehle erstellt, die Sie bewegen KOPF
auf drastische Weise, um die Position des zu erfassen KOPF vor ihrer Operation, also
dass Sie die Spitze des Zweigs problemlos wieder in den Zustand vor dem Ausführen versetzen können
Them. MERGE_HEAD zeichnet die Commits auf, die Sie in Ihrem Zweig zusammenführen
wenn Sie Git Merge ausführen. CHERRY_PICK_HEAD zeichnet den Commit auf, den Sie ausführen
Rosinenpicken, wenn Sie Git Cherry-Pick ausführen.

Beachten Sie, dass einer der refs/* Die oben genannten Fälle können entweder von der stammen $GIT_DIR/refs
Verzeichnis oder aus dem $GIT_DIR/packed-refs Datei. Während die Codierung des Ref-Namens lautet
nicht angegeben, UTF-8 wird bevorzugt, da einige Ausgabeverarbeitungen Ref-Namen in annehmen können
UTF-8.

@
@ alone ist eine Abkürzung für KOPF.

@{ }, z.B master@{gestern}, KOPF@{5 Minuten vor}
Ein Verweis, gefolgt vom Suffix @ mit einer Datumsangabe in einem Klammerpaar
(z.B {gestern}, {1 Monat 2 Wochen 3 Tage 1 Stunde 1 zweite vor} or {1979-02-26
18:30:00}) gibt den Wert der Referenz zu einem früheren Zeitpunkt an. Dieses Suffix kann
darf nur unmittelbar nach einem Referenznamen verwendet werden und die Referenz muss über ein vorhandenes Protokoll verfügen
($GIT_DIR/logs/). Beachten Sie, dass hier der Status Ihres Geräts angezeigt wird aus einer regionalen ref bei einem gegebenen
Zeit; z. B. was in Ihrem Lokal war Master Filiale letzte Woche. Wenn Sie es sich ansehen möchten
Commits, die zu bestimmten Zeiten vorgenommen wurden, siehe --schon seit und --bis um.

@{ }, z.B Meister@{1}
Ein Verweis, gefolgt vom Suffix @ mit einer ordinalen Angabe, die in ein Klammerpaar eingeschlossen ist
(z.B 1 {}, 15 {}) gibt den n-ten vorherigen Wert dieser Referenz an. Zum Beispiel Meister@{1}
ist der unmittelbare vorherige Wert von Master während Meister@{5} ist der 5. vorherige Wert von
Master. Dieses Suffix darf nur unmittelbar nach einem Referenznamen verwendet werden und die Referenz muss
über ein vorhandenes Protokoll verfügen ($GIT_DIR/logs/).

@{ }, z.B @{1}
Sie können die Verwendung @ Konstrukt mit einem leeren Ref-Teil, um an einen Reflog-Eintrag des zu gelangen
aktuelle Filiale. Zum Beispiel, wenn Sie sich in einer Filiale befinden blabla dann @{1} bedeutet das Gleiche wie
blabla@{1}.

@{- }, z.B @{-1}
Das Konstrukt @{- } Bedeutet die Der Zweig/das Commit wurde vor dem aktuellen ausgecheckt
eins.

@{stromaufwärts}, z.B master@{upstream}, @{u}
Das Suffix @{stromaufwärts} zu einem Filialnamen (Kurzform @{u}) bezieht sich auf
Zweig, auf dem der durch Zweigname angegebene Zweig aufbauen soll (konfiguriert
mit Zweig. .remote und branch. .verschmelzen). Ein fehlender Filialname lautet standardmäßig
die aktuelle.

@{drücken}, z.B master@{push}, @{drücken}
Das Suffix @{drücken} meldet den Zweig, „zu dem wir pushen würden“, wenn git push ausgeführt würde
während branchname ausgecheckt wurde (oder die aktuelle KOPF wenn kein Filialname angegeben ist).
Da sich unser Push-Ziel in einem Remote-Repository befindet, melden wir natürlich das lokale
Tracking-Zweig, der diesem Zweig entspricht (d. h. etwas in refs/remotes/).

Hier ein Beispiel zur Verdeutlichung:

$ git config push.default aktuell
$ git config remote.pushdefault myfork
$ git checkout -b mybranch origin/master

$ git rev-parse --symbolic-full-name @{upstream}
Refs/Remotes/Ursprung/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 aus einem davon ziehen
Standort verschieben und an einen anderen verschieben. In einem nicht-dreieckigen Arbeitsablauf @{drücken} ist die gleiche wie
@{stromaufwärts}, und es besteht keine Notwendigkeit dafür.

^, z.B KOPF^, v1.5.1^0
Ein Suffix ^ zu einem Revisionsparameter bedeutet das erste übergeordnete Element dieses Commit-Objekts. ^
Bedeutet die Der Elternteil (d. h ^ entspricht ^1). Als Sonderregel gilt:
^0 bedeutet das Commit selbst und wird verwendet, wenn ist der Objektname eines Tags
Objekt, das auf ein Commit-Objekt verweist.

~, z.B Meister~3
Ein Suffix ~ Zu einem Revisionsparameter gehört das Commit-Objekt, das das ist Th
Generationsvorfahre des benannten Commit-Objekts, der nur den ersten Eltern folgt. Dh
~3 entspricht ^^^ das ist äquivalent zu ^1^1^1. Siehe unten für eine
Veranschaulichung der Verwendung dieses Formulars.

^{ }, z.B v0.99.8^{commit}
Ein Suffix ^ gefolgt von einem in ein Klammerpaar eingeschlossenen Objekttypnamen bedeutet Dereferenzierung
das Objekt bei rekursiv bis zu einem Objekt vom Typ gefunden wird oder das Objekt
kann nicht mehr dereferenziert werden (in diesem Fall kotzen). Zum Beispiel, wenn ist eine
Commit-ish, ^{commit} beschreibt das entsprechende Commit-Objekt. Ebenso, wenn
ist ein Baum, ^{Baum} beschreibt das entsprechende Baumobjekt. ^0 is
eine Abkürzung für ^{commit}.

rev^{Objekt} kann verwendet werden, um sicherzugehen Umdrehung benennt ein Objekt, das existiert, ohne
erfordern Umdrehung um ein Tag zu sein, und ohne Dereferenzierung Umdrehung; weil ein Tag bereits ein ist
Wenn es sich um ein Objekt handelt, muss es nicht einmal dereferenziert werden, um zu einem Objekt zu gelangen.

rev^{tag} kann verwendet werden, um dies sicherzustellen Umdrehung identifiziert ein vorhandenes Tag-Objekt.

^{}, z.B v0.99.8^{}
Ein Suffix ^ gefolgt von einem leeren Klammerpaar bedeutet, dass das Objekt ein Tag sein könnte, und
Dereferenzieren Sie das Tag rekursiv, bis ein Nicht-Tag-Objekt gefunden wird.

^{/ }, z.B HEAD^{/fix böse Insekt}
Ein Suffix ^ auf einen Revisionsparameter, gefolgt von einem Klammerpaar, das eine Textzeile enthält
durch einen Schrägstrich, ist dasselbe wie das :/Fix böse Fehler Syntax unten, mit der Ausnahme, dass sie die zurückgibt
jüngster passender Commit, der von erreichbar ist Bevor ^.

:/, z.B :/Fix böse Fehler
Ein Doppelpunkt, gefolgt von einem Schrägstrich, gefolgt von einem Text, benennt einen Commit, dessen Commit-Nachricht
entspricht dem angegebenen regulären Ausdruck. Dieser Name gibt die jüngste Übereinstimmung zurück
Commit, das von jedem Ref aus erreichbar ist. Wenn die Commit-Nachricht mit a beginnt ! U
muss das wiederholen; die besondere Reihenfolge :/!, gefolgt von etwas anderem als !ist
vorerst reserviert. Der reguläre Ausdruck kann mit jedem Teil der Commit-Nachricht übereinstimmen. Zu
Match-Nachrichten, die mit einer Zeichenfolge beginnen, kann man z. B. verwenden :/^foo.

:, z.B KOPF:README, :LIESMICH, master:./README
Ein Suffix : gefolgt von einem Pfad benennt den Blob oder Baum am angegebenen Pfad im Baum
Objekt, das durch den Teil vor dem Doppelpunkt benannt wird. :Weg (mit einem leeren Teil vor dem
Doppelpunkt) ist ein Sonderfall der nachfolgend beschriebenen Syntax: Im Index aufgezeichneter Inhalt
auf dem angegebenen Pfad. Ein Weg, der mit beginnt ./ or ../ ist relativ zum aktuellen Arbeitsstand
Verzeichnis. Der angegebene Pfad wird so konvertiert, dass er relativ zur Wurzel des Arbeitsbaums ist
Verzeichnis. Dies ist am nützlichsten, um einen Blob oder Baum aus einem Commit oder Baum heraus anzusprechen
hat die gleiche Baumstruktur wie der Arbeitsbaum.

: :, z.B :0:README, :LIESMICH
Ein Doppelpunkt, optional gefolgt von einer Stufennummer (0 bis 3) und einem Doppelpunkt, gefolgt von einem
path, benennt ein Blob-Objekt im Index am angegebenen Pfad. Eine fehlende Etappennummer (und
Der darauf folgende Doppelpunkt benennt einen Eintrag der Stufe 0. Während einer Zusammenführung ist Stufe 1 die
gemeinsamer Vorfahre, Stufe 2 ist die Version des Zielzweigs (normalerweise die aktuelle).
Zweig) und Stufe 3 ist die Version aus dem Zweig, der zusammengeführt wird.

Hier ist eine Illustration von Jon Loeliger. Beide Commit-Knoten B und C sind Eltern des Commits
Knoten A. Übergeordnete Commits werden von links nach rechts sortiert.

GHIJ
\ / \ /
DEF
\ | / \
\ | / |
\|/ |
BC
\ /
\ /
A

A = = A^0
B = A^ = A^1 = A~1
C = A^2 = 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

SPEZIFIKATION BEREICHE

Befehle zum Durchlaufen des Verlaufs wie git log arbeiten mit einer Reihe von Commits, nicht nur mit einem einzelnen
begehen. Zu diesen Befehlen wird eine einzelne Revision mit der in der beschriebenen Notation angegeben
Im vorherigen Abschnitt ist der Satz von Commits gemeint, die von diesem Commit aus nach dem Commit erreichbar sind
Ahnenkette.

Um Commits auszuschließen, die von einem Commit aus erreichbar sind, wird ein Präfix verwendet ^ Notation verwendet wird. Z.B ^r1 r2 Mittel
Commits erreichbar von r2 aber schließen Sie diejenigen aus, von denen aus erreichbar ist r1.

Diese Mengenoperation kommt so oft vor, dass es eine Abkürzung dafür gibt. Wenn Sie zwei haben
verpflichtet r1 und r2 (benannt gemäß der Syntax, die oben im Abschnitt „REVISIONEN ANGEBEN“ erläutert wurde),
Sie können nach Commits fragen, die von r2 aus erreichbar sind, mit Ausnahme derjenigen, die von aus erreichbar sind
r1 von ^r1 r2 und es kann geschrieben werden als r1..r2.

Eine ähnliche Notation r1...r2 heißt symmetrische Differenz von r1 und r2 und ist definiert als
r1 r2 --nicht $(git Merge-Basis --alle r1 r2). Es handelt sich um die Menge der Commits, die erreichbar sind
von einem von beiden r1 or r2 aber nicht von beiden.

In diesen beiden Abkürzungen können Sie ein Ende weglassen und es standardmäßig auf HEAD setzen. Zum Beispiel,
Herkunft.. ist eine Abkürzung für Herkunft..KOPF und fragt: „Was habe ich getan, seit ich von der abgezweigt habe?“
Ursprungszweig?" Ebenso ..Herkunft ist eine Abkürzung für KOPF..Ursprung und fragt: „Was hat das getan?“
Ursprung tun, seit ich von ihnen abgezweigt habe?“ Beachten Sie das .. würde bedeuten KOPF KOPF Das ist leer
Bereich, der von HEAD aus sowohl erreichbar als auch nicht erreichbar ist.

Zwei weitere Abkürzungen zum Benennen einer Menge, die aus einem Commit und seinen übergeordneten Commits besteht
existieren. Die r1^@ Notation bedeutet alle Eltern von r1. r1^! beinhaltet Commit r1 aber schließt alles aus
seiner Eltern.

Um es zusammenzufassen:


Beziehen Sie Commits ein, die erreichbar sind (z. B. Vorfahren von) .

^
Commits ausschließen, die erreichbar sind (z. B. Vorfahren von) .

..
Beziehen Sie Commits ein, von denen aus erreichbar ist aber schließen Sie diejenigen aus, die erreichbar sind
aus . Wenn entweder oder wird weggelassen, der Standardwert ist KOPF.

...
Schließen Sie Commits ein, die von beiden aus erreichbar sind oder aber schließe diejenigen aus, die das tun
sind von beiden aus erreichbar. Wenn entweder oder wird weggelassen, der Standardwert ist KOPF.

^@, z.B KOPF^@
Ein Suffix ^ gefolgt von einem at-Zeichen ist dasselbe wie das Auflisten aller Eltern von
(Das heißt, alles einschließen, was von seinen Eltern aus erreichbar ist, aber nicht den Commit selbst).

^!, z.B KOPF^!
Ein Suffix ^ gefolgt von einem Ausrufezeichen ist dasselbe wie das Geben eines Commits und dann
Alle seine Eltern haben das Präfix ^ um sie (und ihre Vorfahren) auszuschließen.

Hier sind einige Beispiele:

DGHD
DFGHIJDF
^GDHD
^DBEIJFB
B..CC
B...CGHDEBC
^DBCEIJFBC
CIJFC
C^@ IJF
C^! C
F^! DGHDF

Parseopt

Im --parseopt-Modus, git rev-parse Hilft beim Massieren von Optionen zum Einbinden in Shell-Skripte
Dieselben Einrichtungen wie C-Einbauten. Es funktioniert als Optionsnormalisierer (z. B. Teilt einzeln).
schaltet Aggregatwerte um), ein bisschen wie getopt(1) tut.

Es übernimmt über die Standardeingabe die Spezifikation der zu analysierenden und zu verstehenden Optionen,
und gibt auf der Standardausgabe eine geeignete Zeichenfolge aus sh(1) eval ersetzen
Argumente mit normalisierten. Im Fehlerfall wird die Verwendung des Standardfehlers ausgegeben
Stream und wird mit Code 129 beendet.

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

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

Jede Optionszeile hat dieses Format:

* ? SP+ hilft LF


Sein Format ist das kurze Optionszeichen, dann der lange Optionsname, getrennt durch ein
Komma. Beide Teile sind nicht erforderlich, mindestens einer ist jedoch erforderlich. Darf nicht enthalten sein
irgendeines davon Figuren. h,help, dry-run und f sind Beispiele für korrekt
.


sind von *, =, ? oder !.

· Verwenden Sie =, wenn die Option ein Argument akzeptiert.

· Verwenden ? Dies bedeutet, dass die Option ein optionales Argument akzeptiert. Das möchten Sie wahrscheinlich
Verwenden Sie den Modus --stuck-long, um das optionale Argument eindeutig analysieren zu können.

· Verwenden Sie *, um zu bedeuten, dass diese Option nicht in der für die generierten Verwendung aufgeführt werden soll
-h-Argument. Es wird für --help-all angezeigt, wie in dokumentiert gitcli(7).

· Verwenden ! um die entsprechende negierte Long-Option nicht verfügbar zu machen.


, falls angegeben, wird als Name des Arguments in der Hilfeausgabe verwendet, z
Optionen, die Argumente erfordern. wird durch das erste Leerzeichen abgeschlossen. Es ist
Es ist üblich, einen Bindestrich zu verwenden, um Wörter in einem Argumenthinweis mit mehreren Wörtern zu trennen.

Der Rest der Zeile wird nach dem Entfernen der Leerzeichen als verknüpfte Hilfe verwendet
die Option.

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

Beispiel
OPTS_SPEC="\
some-command [Optionen] ...

Some-Command macht Foo und Bar!
--
h,Hilfe zeige die Hilfe

foo eine nette Option --foo
bar= eine coole Option --bar mit einem Argument
baz=arg eine weitere coole Option --baz mit einem benannten Argument
qux?path qux kann ein Pfadargument annehmen, hat aber selbst eine Bedeutung

Ein Optionsgruppen-Header
C? Option C mit einem optionalen Argument“

eval „$(echo „$OPTS_SPEC“ | git rev-parse --parseopt – „$@“ || echo exit $?)“

Anwendungsbereich Text
Wenn „$@“ im obigen Beispiel -h oder --help ist, wird der folgende Verwendungstext angezeigt:

Verwendung: some-command [Optionen] ...

Some-Command macht Foo und Bar!

-h, --help zeigt die Hilfe an
--foo eine nette Option --foo
--bar ... eine coole Option --bar mit einem Argument
--baz eine weitere coole Option --baz mit einem benannten Argument
--qux[= ] qux kann ein Pfadargument annehmen, hat aber eine eigenständige Bedeutung

Ein Optionsgruppen-Header
-C[...] Option C mit einem optionalen Argument

SQ-Zitat

Im --sq-quote-Modus, git rev-parse Echos auf der Standardausgabe einer einzelnen Zeile geeignet für
sh(1) Bewertung. Diese Zeile wird durch Normalisierung der Argumente nach --sq-quote erstellt. Nichts
Anders als das Zitieren der Argumente ist erledigt.

Wenn Sie möchten, dass die Befehlseingabe weiterhin wie gewohnt interpretiert wird git rev-parse Vor dem
Die Ausgabe wird in Shell-Anführungszeichen gesetzt, siehe Option --sq.

Beispiel
$ cat >your-git-script.sh <<\EOF
#!/ Bin / sh
args=$(git rev-parse --sq-quote "$@") # Vom Benutzer bereitgestellte Argumente in Anführungszeichen setzen
command="git frotz -n24 $args" # und verwenden Sie es in einem handgefertigten
# Befehlszeile
eval „$command“
EOF

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

Beispiele:

· Geben Sie den Objektnamen des aktuellen Commits aus:

$ git rev-parse --verify HEAD

· Geben Sie den Commit-Objektnamen aus der Revision in der Shell-Variablen $REV aus:

$ git rev-parse --verify $REV^{commit}

Dies führt zu einem Fehler, wenn $REV leer oder keine gültige Revision ist.

· Ähnlich wie oben:

$ git rev-parse --default master --verify $REV

aber wenn $REV leer ist, wird der Commit-Objektname vom Master ausgegeben.

GIT

Ein Teil des git(1) Suite

Verwenden Sie git-rev-parse online über die Dienste von onworks.net