git-rev-list – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

git-rev-list – Listet Commit-Objekte in umgekehrter chronologischer Reihenfolge auf

ZUSAMMENFASSUNG

git Drehzahlliste [ --max-count= ]
[ --skip= ]
[ --max-age= ]
[ --min-age= ]
[ --spärlich ]
[ --merges ]
[ --no-merges ]
[ --min-parents= ]
[ --no-min-parents ]
[ --max-parents= ]
[ --no-max-parents ]
[ --first-parent ]
[ --remove-empty ]
[ --full-history ]
[ --nicht ]
[ --alle ]
[ --branches[= ] ]
[ --tags[= ] ]
[ --remotes[= ] ]
[ --glob= ]
[ --ignore-missing ]
[ --stdin ]
[ --ruhig ]
[ --topo-order ]
[ --Eltern ]
[ --timestamp ]
[ --links rechts ]
[ --left-only]
[ --right-only]
[ --cherry-mark ]
[ --cherry-pick ]
[ --encoding= ]
[ --(author|committer|grep)= ]
[ --regexp-ignore-case | -ich ]
[ --extended-regexp | -E]
[ --fixed-strings | -F ]
[ --date= ]
[ [ --objects | --objects-edge | --objects-edge-aggressive ]
[ --unverpackt ] ]
[ --pretty | --Header ]
[ --bisect ]
[ --bisect-vars ]
[ --bisect-all ]
[ --merge ]
[ --umkehren ]
[ --walk-reflogs ]
[ --no-walk ] [ --do-walk ]
[ --zählen ]
[ --use-bitmap-index ]
... [ -- ... ]

BESCHREIBUNG

Listen Sie Commits auf, die erreichbar sind, indem Sie den übergeordneten Links der angegebenen Commits folgen.
Schließen Sie jedoch Commits aus, die von den mit a angegebenen Commits aus erreichbar sind ^ vor ihnen.
Die Ausgabe erfolgt standardmäßig in umgekehrter chronologischer Reihenfolge.

Sie können sich dies als Mengenoperation vorstellen. Auf der Befehlszeile angegebene Commits bilden eine Reihe von
Commits, die von jedem von ihnen aus erreichbar sind, und dann Commits, die von jedem von ihnen aus erreichbar sind
diejenigen, die mit gegeben wurden ^ vorn werden von dieser Menge abgezogen. Die verbleibenden Commits sind was
erscheint in der Ausgabe des Befehls. Verschiedene andere Optionen und Pfadparameter können verwendet werden
um das Ergebnis weiter einzuschränken.

Daher der folgende Befehl:

$ git rev-list foo bar ^baz

bedeutet „Alle Commits auflisten, von denen aus erreichbar ist.“ foo or Bar, aber nicht von baz".

Eine besondere Notation“..„kann als Abkürzung für „^“ verwendet werden. '
". Beispielsweise kann eine der folgenden Bedeutungen austauschbar verwendet werden:

$ git rev-list origin..HEAD
$ git rev-list HEAD ^origin

Eine weitere besondere Notation ist „..." was für Zusammenführungen nützlich ist. Die
Der resultierende Satz von Commits ist die symmetrische Differenz zwischen den beiden Operanden. Der
Die folgenden zwei Befehle sind äquivalent:

$ git rev-list AB --not $(git merge-base --all AB)
$ git rev-list A...B

Drehzahlliste ist ein sehr wichtiger Git-Befehl, da er die Möglichkeit bietet, zu erstellen und
Commit-Abstammungsdiagramme durchqueren. Aus diesem Grund gibt es viele verschiedene Optionen
ermöglicht die Verwendung durch so unterschiedliche Befehle wie git halbieren und git Verpacken.

OPTIONAL

Verpflichten Begrenzung
Neben der Angabe einer Reihe von Commits, die mithilfe der speziellen Notationen aufgelistet werden sollen
Wie in der Beschreibung erläutert, kann eine zusätzliche Commit-Beschränkung angewendet werden.

Die Verwendung weiterer Optionen schränkt die Ausgabe im Allgemeinen weiter ein (z. B. --since= Grenzen zu
begeht neuere als und es mit --grep= verwenden weitere Grenzen für Commits
deren Protokollnachricht eine entsprechende Zeile enthält ), wenn nicht anders angegeben.

Beachten Sie, dass diese vor den Commit-Reihenfolge- und Formatierungsoptionen angewendet werden, z
--umkehren.

- , -N , --max-count=
Begrenzen Sie die Anzahl der auszugebenden Commits.

--skip=
überspringen Anzahl führt Commits aus, bevor mit der Anzeige der Commit-Ausgabe begonnen wird.

--since= , --after=
Commits anzeigen, die neuer als ein bestimmtes Datum sind.

--until= , --before=
Commits anzeigen, die älter als ein bestimmtes Datum sind.

--max-age= , --min-age=
Beschränken Sie die Commit-Ausgabe auf den angegebenen Zeitraum.

--author= , --committer=
Beschränken Sie die Commit-Ausgabe auf solche mit Autoren-/Committer-Headerzeilen, die mit dem übereinstimmen
angegebenes Muster (regulärer Ausdruck). Mit mehr als einem --author= , begeht
ausgewählt, deren Autor mit einem der angegebenen Muster übereinstimmt (ähnlich wie bei mehreren).
--committer= ).

--grep-reflog=
Beschränken Sie die Commit-Ausgabe auf solche mit Reflog-Einträgen, die dem angegebenen Muster entsprechen
(regulären Ausdruck). Mit mehr als einem --grep-reflog, Commits, deren Reflog-Nachricht
Es werden alle Muster ausgewählt, die mit einem der angegebenen Muster übereinstimmen. Es ist ein Fehler, diese Option zu verwenden, es sei denn
--walk-reflogs wird verwendet.

--grep=
Beschränken Sie die Commit-Ausgabe auf solche mit einer Protokollnachricht, die dem angegebenen Muster entspricht
(regulären Ausdruck). Mit mehr als einem --grep= , begeht dessen Nachricht
Übereinstimmungen mit einem der angegebenen Muster werden ausgewählt (siehe jedoch --all-match).

--all-match
Beschränken Sie die Commit-Ausgabe auf diejenigen, die mit allen angegebenen --grep übereinstimmen, anstatt auf diejenigen, die dies tun
stimmen mit mindestens einem überein.

--invert-grep
Beschränken Sie die Commit-Ausgabe auf solche mit Protokollmeldungen, die nicht dem Muster entsprechen
angegeben mit --grep= .

-i, --regexp-ignore-case
Passen Sie die Muster zur Begrenzung regulärer Ausdrücke an, ohne Rücksicht auf die Groß-/Kleinschreibung.

--basic-regexp
Betrachten Sie die begrenzenden Muster als grundlegende reguläre Ausdrücke. Dies ist die Standardeinstellung.

-E, --extended-regexp
Betrachten Sie die einschränkenden Muster als erweiterte reguläre Ausdrücke anstelle von
Standardmäßig grundlegende reguläre Ausdrücke.

-F, --fixed-strings
Betrachten Sie die begrenzenden Muster als feste Zeichenfolgen (interpretieren Sie Muster nicht als
regulären Ausdruck).

--perl-regexp
Betrachten Sie die begrenzenden Muster als Perl-kompatible reguläre Ausdrücke. Erfordert
libpcre, das kompiliert werden soll.

--remove-empty
Stoppen Sie, wenn ein bestimmter Pfad aus dem Baum verschwindet.

--fusioniert
Nur Merge-Commits drucken. Dies ist genau das Gleiche wie --min-parents=2.

--no-merges
Drucken Sie keine Commits mit mehr als einem übergeordneten Element. Das ist genau das Gleiche wie
--max-parents=1.

--min-parents= , --max-parents= , --no-min-parents, --no-max-parents
Zeigt nur Commits an, die mindestens (oder höchstens) so viele übergeordnete Commits haben. In
Insbesondere ist --max-parents=1 dasselbe wie --no-merges, --min-parents=2 ist dasselbe wie
--fusioniert. --max-parents=0 gibt alle Root-Commits und --min-parents=3 alle Octopus
verschmilzt.

--no-min-parents und --no-max-parents setzen diese Grenzwerte wieder zurück (auf „no limit“).
Äquivalente Formen sind --min-parents=0 (jeder Commit hat 0 oder mehr Eltern) und
--max-parents=-1 (negative Zahlen bedeuten keine Obergrenze).

--erster Elternteil
Befolgen Sie nur den ersten übergeordneten Commit, wenn Sie einen Merge-Commit sehen. Diese Option kann eine geben
Besserer Überblick bei der Betrachtung der Entwicklung eines bestimmten Themenzweigs, weil
Beim Zusammenführen in einen Themenzweig geht es in der Regel nur um die Anpassung an aktualisierte Upstreams
von Zeit zu Zeit, und diese Option ermöglicht es Ihnen, die einzelnen eingebrachten Commits zu ignorieren
zu Ihrer Geschichte durch eine solche Zusammenführung. Kann nicht mit --bisect kombiniert werden.

--nicht
Kehrt die Bedeutung von um ^ Präfix (oder dessen Fehlen) für alle folgenden Revisionen
Spezifizierer, bis zum nächsten --not.

--alle
Tun Sie so, als ob alle Refs in refs/ in der Befehlszeile als aufgeführt wären .

--branches[= ]
Tun Sie so, als ob alle Refs in refs/heads in der Befehlszeile als aufgeführt wären .
If gegeben ist, beschränken Sie die Zweige auf diejenigen, die mit dem gegebenen Shell-Glob übereinstimmen. Wenn Muster
fehlt ?, *oder [, /* am Ende ist impliziert.

--tags[= ]
Tun Sie so, als ob alle Refs in refs/tags in der Befehlszeile als aufgeführt wären . Wenn
gegeben ist, beschränken Sie die Tags auf solche, die mit dem gegebenen Shell-Glob übereinstimmen. Wenn Muster fehlt ?,
*oder [, /* am Ende ist impliziert.

--remotes[= ]
Tun Sie so, als ob alle Refs in refs/remotes in der Befehlszeile als aufgeführt wären .
If gegeben ist, beschränken Sie die Remote-Tracking-Zweige auf solche, die der gegebenen Shell entsprechen
Kugel. Wenn Muster fehlt ?, *oder [, /* am Ende ist impliziert.

--glob=
Stellen Sie sich vor, als ob alle Refs mit dem Shell-Glob übereinstimmen würden sind auf der gelistet
Befehlszeile als . Führend refs/, wird automatisch vorangestellt, wenn es fehlt. Wenn
Muster fehlt ?, *oder [, /* am Ende ist impliziert.

--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.

--reflog
Stellen Sie sich vor, als ob alle in Reflogs erwähnten Objekte in der Befehlszeile als aufgeführt wären
.

--ignore-missing
Wenn Sie in der Eingabe einen ungültigen Objektnamen sehen, tun Sie so, als wäre die Eingabe falsch
gegeben.

--stdin
Neben der in der Befehlszeile aufgelistet sind, lesen Sie sie aus dem Standard
Eingang. Wenn ein -- Trennzeichen angezeigt wird, beenden Sie das Lesen von Commits und beginnen Sie mit dem Lesen von Pfaden zu
das Ergebnis einschränken.

--ruhig
Drucken Sie nichts auf der Standardausgabe. Dieses Formular dient in erster Linie dazu, dies zu ermöglichen
Aufrufer, den Exit-Status zu testen, um zu sehen, ob eine Reihe von Objekten vollständig verbunden ist (oder
nicht). Dies ist schneller als die Umleitung von stdout nach /dev/null, da die Ausgabe dies nicht tun muss
formatiert werden.

--cherry-mark
Wie --cherry-pick (siehe unten), aber kennzeichnen Sie äquivalente Commits mit =, anstatt sie wegzulassen
sie und ungleiche mit +.

--Rosinenpickel
Lassen Sie jeden Commit weg, der die gleiche Änderung einführt wie ein anderer Commit auf der „anderen Seite“.
wenn die Menge der Commits mit symmetrischer Differenz begrenzt ist.

Wenn Sie beispielsweise zwei Zweige haben, A und B, ist dies eine übliche Methode zum Auflisten aller Commits
nur eine Seite davon ist mit --left-right versehen (siehe Beispiel unten in der Beschreibung).
der Option --left-right). Es zeigt jedoch die Commits, die ausgewählt wurden
aus dem anderen Zweig (zum Beispiel kann „3. auf b“ aus Zweig A ausgewählt werden).
Mit dieser Option werden solche Commits-Paare von der Ausgabe ausgeschlossen.

--left-only, --right-only
List-Commits erfolgen nur auf der jeweiligen Seite eines symmetrischen Bereichs, also nur auf denen, die
würde mit < bzw. markiert werden. > durch --left-right.

Zum Beispiel lässt --cherry-pick --right-only A...B die Commits von B weg, die in sind
A oder sind Patch-Äquivalent zu einem Commit in A. Mit anderen Worten: Hier werden die + Commits aufgelistet
von Git Cherry A B. Genauer gesagt, --cherry-pick --right-only --no-merges gibt das
genaue Liste.

--Kirsche
Ein Synonym für --right-only --cherry-mark --no-merges; nützlich, um die Ausgabe auf zu beschränken
die Commits auf unserer Seite und markieren diejenigen, die auf der anderen Seite von a angewendet wurden
Gespaltener Verlauf mit git log --cherry upstream...mybranch, ähnlich wie git Cherry
Upstream-Mybranch.

-g, --walk-reflogs
Anstatt die Commit-Abstammungskette zu durchlaufen, gehen Sie die Reflog-Einträge der aktuellsten durch
eins zu älteren. Wenn diese Option verwendet wird, können Sie keine auszuschließenden Commits angeben
(das ist, ^verpflichten, commit1..commit2sowie commit1...commit2 Notationen können nicht verwendet werden).

Bei einem anderen --pretty-Format als oneline (aus offensichtlichen Gründen) führt dies zur Ausgabe
um zwei zusätzliche Informationszeilen aus dem Reflog zu erhalten. Standardmäßig, commit@{Nth}
In der Ausgabe wird die Notation verwendet. Wenn das Start-Commit als angegeben ist Tue es jetzt},
Ausgabe verwendet auch commit@{timestamp} stattdessen die Notation. Unter --pretty=oneline wird die
Der Commit-Nachricht werden diese Informationen in derselben Zeile vorangestellt. Diese Option kann nicht
mit --reverse kombiniert werden. Siehe auch git-reflog(1).

--verschmelzen
Zeigen Sie nach einer fehlgeschlagenen Zusammenführung Refs an, die Dateien berühren, bei denen ein Konflikt vorliegt und die nicht vorhanden sind
Alle Köpfe verschmelzen.

--Grenze
Ausgabe ausgeschlossener Grenz-Commits. Grenz-Commits werden mit dem Präfix - versehen.

--use-bitmap-index
Versuchen Sie, die Durchquerung mithilfe des Pack-Bitmap-Index (sofern verfügbar) zu beschleunigen. Notiz
dass Bäume und Blobs beim Durchlaufen mit --objects nicht verknüpft sind
Pfad gedruckt.

Geschichte Vereinfachung
Manchmal interessieren Sie sich nur für Teile des Verlaufs, beispielsweise für die Commits
eine bestimmte Sache ändern . Aber es gibt zwei Teile davon Geschichte Vereinfachung, ein Teil
ist die Auswahl der Commits und die andere ist, wie man es macht, da es dafür verschiedene Strategien gibt
Vereinfachen Sie die Geschichte.

Die folgenden Optionen wählen die anzuzeigenden Commits aus:


Commits, die das Gegebene ändern ausgewählt sind.

--simplify-by-decoration
Es werden Commits ausgewählt, auf die von einem Zweig oder Tag verwiesen wird.

Beachten Sie, dass zusätzliche Commits angezeigt werden können, um einen aussagekräftigen Verlauf zu erhalten.

Die folgenden Optionen beeinflussen die Art und Weise, wie die Vereinfachung durchgeführt wird:

Standardmodus
Vereinfacht den Verlauf auf den einfachsten Verlauf, der den Endzustand des Baums erklärt.
Am einfachsten, da einige Seitenzweige beschnitten werden, wenn das Endergebnis dasselbe ist (d. h
Zusammenführen von Zweigen mit demselben Inhalt)

--full-history
Entspricht dem Standardmodus, löscht jedoch keinen Teil des Verlaufs.

--dicht
Es werden nur die ausgewählten Commits angezeigt, außerdem einige, um einen aussagekräftigen Verlauf zu erhalten.

--spärlich
Alle Commits im vereinfachten Verlauf werden angezeigt.

--simplify-merges
Zusätzliche Option zu --full-history, um einige unnötige Zusammenführungen aus dem Ergebnis zu entfernen
Verlauf, da keine ausgewählten Commits zu dieser Zusammenführung beitragen.

--ancestry-path
Wenn eine Reihe von Commits angezeigt werden sollen (z commit1..commit2 or commit2 ^commit1),
Zeigen Sie nur Commits an, die direkt in der Abstammungskette zwischen den vorhanden sind commit1 und
commit2, also Commits, die beide Nachkommen von sind commit1, und Vorfahren von commit2.

Eine ausführlichere Erklärung folgt.

Angenommen, Sie haben foo als angegeben . Wir nennen Commits, die foo modifizieren, !TREESAME,
und der Rest TREESAME. (In einem nach foo gefilterten Diff sehen sie unterschiedlich und gleich aus,
beziehungsweise.)

Im Folgenden beziehen wir uns zur Veranschaulichung immer auf die gleiche Beispielhistorie
Unterschiede zwischen den Vereinfachungseinstellungen. Wir gehen davon aus, dass Sie nach einer Datei filtern
foo in diesem Commit-Diagramm:

.-A---M---N---O---P---Q
/ / / / / /
IBCDEY
\ / / / / /
`-------------' X

Die horizontale Verlaufslinie A---Q wird als erstes übergeordnetes Element jeder Zusammenführung angesehen. Der
Commits sind:

· I ist das anfängliche Commit, in dem foo mit dem Inhalt „asdf“ und einer Datei quux existiert
existiert mit dem Inhalt „quux“. Erste Commits werden mit einem leeren Baum verglichen, also bin ich es auch
!TREESAME.

· In A enthält foo nur „foo“.

· B enthält die gleiche Änderung wie A. Seine Zusammenführung M ist trivial und daher für alle TREESAME
Eltern.

· C ändert foo nicht, aber sein merge N ändert es in „foobar“, also ist es nicht TREESAME
an alle Eltern.

· D setzt foo auf „baz“. Seine Zusammenführung O kombiniert die Saiten von N und D zu „foobarbaz“;
Das heißt, es ist für keinen Elternteil TREESAME.

· E ändert quux in „xyzzy“ und seine Zusammenführung P kombiniert die Zeichenfolgen zu „quux xyzzy“. P ist
TREESAME zu O, aber nicht zu E.

· X ist ein unabhängiger Root-Commit, der eine neue Dateiseite hinzugefügt hat, und Y hat sie geändert. Y ist
TREESAME zu

rev-list geht rückwärts durch den Verlauf und schließt Commits ein oder aus, je nachdem, ob
--full-history und/oder parent rewriting (über --parents oder --children) werden verwendet. Der
Folgende Einstellungen stehen zur Verfügung.

Standardmodus
Commits sind enthalten, wenn sie für kein übergeordnetes Element TREESAME sind (dies kann jedoch der Fall sein).
geändert, siehe --sparse unten). Wenn das Commit eine Zusammenführung war und es TREESAME zu eins war
Elternteil, folge nur diesem Elternteil. (Auch wenn es mehrere TREESAME-Eltern gibt, folgen Sie
nur einer von ihnen.) Ansonsten folgen Sie allen Eltern.

Das führt zu:

.-A---N---O
///
AUSWEIS

Beachten Sie, dass die Regel, nur dem TREESAME-Elternteil zu folgen, wenn eines verfügbar ist, B entfernt hat
völlig aus der Betrachtung. C wurde über N berücksichtigt, ist aber TREESAME. Root-Commits
werden mit einem leeren Baum verglichen, also ist ich !TREESAME.

Eltern-/Kind-Beziehungen sind nur mit --parents sichtbar, aber das hat keinen Einfluss auf die
Commits sind im Standardmodus ausgewählt, daher haben wir die übergeordneten Zeilen angezeigt.

--full-history ohne Umschreiben des übergeordneten Elements
Dieser Modus unterscheidet sich in einem Punkt vom Standardmodus: Befolgen Sie immer alle übergeordneten Elemente einer Zusammenführung.
selbst wenn es für einen von ihnen TREESAME ist. Auch wenn mehr als eine Seite der Zusammenführung vorhanden ist
Commits, die enthalten sind, bedeutet dies nicht, dass die Zusammenführung selbst erfolgt! Im
Beispiel, wir bekommen

IABNDOPQ

M wurde ausgeschlossen, da es für beide Elternteile TREESAME ist. E, C und B wurden alle gelaufen,
aber nur B war !TREESAME, daher erscheinen die anderen nicht.

Beachten Sie, dass es ohne übergeordnetes Umschreiben nicht wirklich möglich ist, darüber zu sprechen
Eltern-/Kind-Beziehungen zwischen den Commits, daher zeigen wir, dass sie nicht miteinander verbunden sind.

--full-history mit übergeordnetem Umschreiben
Gewöhnliche Commits sind nur enthalten, wenn sie !TREESAME sind (obwohl dies geändert werden kann,
siehe --sparse unten).

Zusammenführungen sind immer enthalten. Ihre übergeordnete Liste wird jedoch umgeschrieben: Entlang jeder
Übergeordnetes Element: Entfernen Sie Commits, die selbst nicht enthalten sind. Das führt zu

.-A---M---N---O---P---Q
/ / / / /
IB / D /
\ / / / /
`-------------'

Vergleichen Sie mit --full-history ohne Umschreiben oben. Beachten Sie, dass E weggeschnitten wurde, weil
es ist TREESAME, aber die übergeordnete Liste von P wurde umgeschrieben, um das übergeordnete I von E zu enthalten
Dasselbe geschah für C und N sowie X, Y und Q.

Zusätzlich zu den oben genannten Einstellungen können Sie ändern, ob TREESAME die Aufnahme beeinflusst:

--dicht
Durchgegangene Commits sind enthalten, wenn sie für kein übergeordnetes Element TREESAME sind.

--spärlich
Alle ausgeführten Commits sind enthalten.

Beachten Sie, dass dies ohne --full-history Zusammenführungen immer noch vereinfacht: wenn einer der Eltern
ist TREESAME, wir folgen nur diesem, die anderen Seiten der Zusammenführung also nie
ging.

--simplify-merges
Erstellen Sie zunächst ein Verlaufsdiagramm auf die gleiche Weise wie --full-history mit übergeordnetem Umschreiben
tut (siehe oben).

Vereinfachen Sie dann jedes Commit C zu seinem Ersatz C' im endgültigen Verlauf gemäß
folgende Regeln:

· Setzen Sie C' auf C.

· Ersetzen Sie jedes Elternteil P von C' durch seine Vereinfachung P'. Dabei fallen lassen
Eltern, die Vorfahren anderer Eltern sind oder Root-Commits für TREESAME sind
einen leeren Baum und entfernen Sie Duplikate, aber achten Sie darauf, dass Sie niemals alle übergeordneten Elemente löschen
Wir sind TREESAME dazu.

· Wenn nach diesem übergeordneten Umschreiben C' ein Root- oder Merge-Commit ist (null oder >1 hat).
Eltern), ein Boundary Commit oder !TREESAME, es bleibt bestehen. Andernfalls wird es ersetzt
mit seinem einzigen Elternteil.

Der Effekt lässt sich am besten anhand eines Vergleichs mit --full-history und parent veranschaulichen
Umschreiben. Das Beispiel wird zu:

.-BIN NEIN
///
IBD
\ / /
„---------“

Beachten Sie die Hauptunterschiede in N, P und Q gegenüber --full-history:

· Die Elternliste von N musste ich entfernen, da sie ein Vorfahre des anderen Elternteils M ist.
Dennoch blieb N bestehen, da es !TREESAME ist.

· Die Elternliste von P hatte ich ebenfalls entfernt. P wurde dann komplett entfernt, weil
es hatte einen Elternteil und ist TREESAME.

· In der übergeordneten Liste von Q wurde Y zu X vereinfacht. X wurde dann entfernt, weil es ein war
TREESAME-Wurzel. Q wurde dann vollständig entfernt, da es ein Elternteil hatte und es ist
TREESAME.

Schließlich steht noch ein fünfter Vereinfachungsmodus zur Verfügung:

--ancestry-path
Beschränken Sie die angezeigten Commits auf diejenigen, die sich direkt in der Abstammungskette zwischen dem „Von“ befinden.
und „bis“ führt Commits im angegebenen Commit-Bereich durch. Dh nur Commits anzeigen, die es sind
Vorfahr des „to“-Commits und Nachkommen des „from“-Commits.

Betrachten Sie als Beispielanwendungsfall den folgenden Commit-Verlauf:

D---E-------F
/ \.
B---C---G---H---I---J
/
A-------K---------------L--M

Ein Stammkunde DM berechnet die Menge der Commits, die Vorfahren von M sind, schließt diese jedoch aus
diejenigen, die Vorfahren von D sind. Dies ist nützlich, um zu sehen, was mit der Geschichte passiert ist
was seit D zu M führt, in dem Sinne: „Was hat M, was in D nicht existierte“.
Das Ergebnis in diesem Beispiel wären alle Commits außer A und B (und D selbst).
Kurs).

Wenn wir herausfinden möchten, welche Commits in M ​​mit dem durch eingeführten Fehler kontaminiert sind
D und müssen repariert werden, wir möchten jedoch möglicherweise nur die Teilmenge davon anzeigen DM Das hat
eigentlich Nachkommen von D, also ohne C und K. Das ist genau das, was die
Die Option --ancestry-path funktioniert. Angewendet auf die DM Bereich, es ergibt sich:

E-------F
\
G---H---I---J

L--M

Mit der Option --simplify-by-decoration können Sie nur das Gesamtbild anzeigen
Topologie des Verlaufs, indem Commits weggelassen werden, auf die nicht durch Tags verwiesen wird. Commits sind
als !TREESAME markiert (d. h. nach den beschriebenen Vereinfachungsregeln für den Verlauf aufbewahrt).
oben), wenn (1) sie durch Tags referenziert werden oder (2) sie den Inhalt der Pfade ändern
in der Befehlszeile angegeben. Alle anderen Commits sind als TREESAME markiert (vorbehaltlich
vereinfacht weg).

Halbierung Helpers
--halbieren
Beschränken Sie die Ausgabe auf das eine Commit-Objekt, das ungefähr in der Mitte zwischen enthalten und liegt
ausgeschlossene Commits. Beachten Sie, dass die fehlerhafte Halbierungsreferenz refs/bisect/bad zum hinzugefügt wird
enthaltene Commits (falls vorhanden) und die guten Halbierungsrefs refs/bisect/good-* sind
zu den ausgeschlossenen Commits hinzugefügt (sofern vorhanden). Angenommen, es sind keine Refs vorhanden
refs/bisect/, wenn

$ git rev-list --bisect foo ^bar ^baz

Ausgänge Mittelpunkt, die Ausgabe der beiden Befehle

$ git rev-list foo ^midpoint
$ git rev-list midpoint ^bar ^baz

wäre ungefähr gleich lang. Finden der Veränderung, die eine Regression einleitet
wird somit auf eine binäre Suche reduziert: immer wieder neue „Mittelpunkte“ generieren und testen, bis
Die Commit-Kette hat die Länge eins. Kann nicht mit --first-parent kombiniert werden.

--bisect-vars
Dies berechnet dasselbe wie --bisect, außer dass Refs in refs/bisect/ nicht verwendet werden.
und mit der Ausnahme, dass dadurch Text ausgegeben wird, der von der Shell ausgewertet werden kann. Diese Zeilen werden
Weisen Sie der Variablen bisect_rev den Namen der Mittelpunktrevision und den erwarteten Wert zu
Anzahl der Commits, die getestet werden sollen, nachdem bisect_rev auf bisect_nr, den erwarteten Wert, getestet wurde
Anzahl der zu testenden Commits, wenn sich herausstellt, dass bisect_rev gut zu bisect_good ist
erwartete Anzahl der zu testenden Commits, wenn sich herausstellt, dass bisect_rev fehlerhaft ist
bisect_bad und die Anzahl der Commits, die wir gerade halbieren, bisect_all.

--bisect-all
Dadurch werden alle Commit-Objekte zwischen den eingeschlossenen und ausgeschlossenen Commits geordnet ausgegeben
durch ihre Entfernung zu den eingeschlossenen und ausgeschlossenen Commits. Refs in refs/bisect/ sind es nicht
gebraucht. Die am weitesten von ihnen entfernte Seite wird zuerst angezeigt. (Dies ist die einzige, die von angezeigt wird
--halbieren.)

Dies ist nützlich, da es einfacher ist, einen guten Commit zum Testen auszuwählen, wann immer Sie möchten
um zu vermeiden, dass einige von ihnen aus irgendeinem Grund getestet werden (sie können beispielsweise nicht kompiliert werden).

Diese Option kann zusammen mit --bisect-vars verwendet werden, in diesem Fall nach der Sortierung
Beim Festschreiben von Objekten wird derselbe Text angezeigt, als ob --bisect-vars allein verwendet worden wäre.

Verpflichten Bestellung
Standardmäßig werden die Commits in umgekehrter chronologischer Reihenfolge angezeigt.

--date-order
Zeigt keine übergeordneten Elemente an, bevor alle untergeordneten Elemente angezeigt werden. Andernfalls werden Commits angezeigt
die Commit-Zeitstempelreihenfolge.

--author-date-order
Zeigt keine übergeordneten Elemente an, bevor alle untergeordneten Elemente angezeigt werden. Andernfalls werden Commits angezeigt
die Zeitstempelreihenfolge des Autors.

--topo-order
Zeigen Sie keine übergeordneten Elemente an, bevor alle untergeordneten Elemente angezeigt werden, und vermeiden Sie die Anzeige von Commits
Mehrere Linien der Geschichte vermischten sich.

Zum Beispiel in einem Commit-Verlauf wie diesem:

---1----2----4----7
\

3----5----6----8---
Dabei geben die Zahlen die Reihenfolge der Commit-Zeitstempel, der Git-Rev-Liste und der Freunde an
--date-order zeigt die Commits in der Zeitstempelreihenfolge an: 8 7 6 5 4 3 2 1.

Mit --topo-order würden sie 8 6 5 3 7 4 2 1 (oder 8 7 4 2 6 5 3 1) anzeigen; einige älter
Commits werden vor neueren angezeigt, um zu vermeiden, dass die Commits von zwei angezeigt werden
parallele Entwicklungsspur gemischt.

--umkehren
Geben Sie die Commits in umgekehrter Reihenfolge aus. Kann nicht mit --walk-reflogs kombiniert werden.

Betreff Traversal
Diese Optionen zielen hauptsächlich auf das Packen von Git-Repositorys ab.

--Objekte
Gibt die Objekt-IDs aller Objekte aus, auf die von den aufgelisteten Commits verwiesen wird. --objects foo
^bar bedeutet also „Sende mir alle Objekt-IDs, die ich herunterladen muss, wenn ich das Commit habe.“
Objekt Bar aber nicht foo".

--objects-edge
Ähnlich wie --objects, aber gibt auch die IDs der ausgeschlossenen Commits mit dem Präfix „-“ aus.
Charakter. Dies wird von verwendet Git-Pack-Objekte(1) ein „dünnes“ Paket zu bauen, das aufzeichnet
Objekte in deltifizierter Form basierend auf Objekten, die in diesen ausgeschlossenen Commits enthalten sind
Reduzieren Sie den Netzwerkverkehr.

--objects-edge-aggressive
Ähnlich wie --objects-edge, aber es wird auf Kosten von mehr versucht, ausgeschlossene Commits zu finden
erhöhte Zeit. Dies wird anstelle von --objects-edge verwendet, um „dünne“ Pakete zu erstellen
flache Repositories.

--indexed-objects
Tun Sie so, als ob alle vom Index verwendeten Bäume und Blobs in der Befehlszeile aufgelistet wären.
Beachten Sie, dass Sie wahrscheinlich auch --objects verwenden möchten.

--unverpackt
Nur nützlich mit --objects; Drucken Sie die Objekt-IDs aus, die nicht in Paketen enthalten sind.

--no-walk[=(sortiert|unsortiert)]
Zeigt nur die angegebenen Commits an, durchläuft jedoch nicht deren Vorfahren. Dies hat keine Auswirkung
wenn ein Bereich angegeben ist. Wenn das Argument unsorted angegeben ist, werden die Commits in angezeigt
der Befehl, der ihnen in der Befehlszeile gegeben wurde. Ansonsten (falls sortiert oder kein Argument vorhanden war
angegeben), werden die Commits in umgekehrter chronologischer Reihenfolge nach Commit-Zeitpunkt angezeigt. Kann nicht sein
kombiniert mit --graph.

--do-walk
Überschreibt ein vorheriges --no-walk.

Verpflichten Formatierung:
Mit diesen Optionen können Sie git-rev-Liste(1) verhält sich ähnlich wie die spezialisiertere Familie von
Commit-Log-Tools: Git-Log(1) Git-Show(1) und git-whatchanged(1)

--pretty[= ], --format=
Drucken Sie den Inhalt der Festschreibungsprotokolle hübsch in einem bestimmten Format aus kann sein
eine eine Linie, kurz, mittlere, voller, voller, E-Mail, roh, Format: und
Format:. Wenn ist keines der oben genannten und hat %Platzhalter darin, es
tut so, als ob --pretty=tformat: wurden gegeben.

Weitere Details zu den einzelnen Formaten finden Sie im Abschnitt „HÜBSCHE FORMATE“. Wenn
= Teil wird weggelassen, es wird standardmäßig verwendet mittlere.

Hinweis: Sie können das Standard-Pretty-Format in der Repository-Konfiguration angeben (siehe
git-config(1)).

--abbrev-commit
Anstatt den vollständigen 40-Byte-Hexadezimal-Commit-Objektnamen anzuzeigen, zeigen Sie nur a an
Teilpräfix. Eine nicht standardmäßige Anzahl von Ziffern kann mit „--abbrev=“ angegeben werden "
(was auch die Diff-Ausgabe ändert, falls sie angezeigt wird).

Dies sollte „--pretty=oneline“ für Benutzer viel lesbarer machen
80-Spalten-Terminals.

--no-abbrev-commit
Zeigt den vollständigen 40-Byte-Hexadezimal-Commit-Objektnamen an. Dies negiert --abbrev-commit und
die Optionen, die dies implizieren, wie zum Beispiel „--oneline“. Es überschreibt auch die
log.abbrevCommit variabel.

--eine Linie
Dies ist eine Kurzform für die gemeinsame Verwendung von „--pretty=oneline --abbrev-commit“.

--encoding=
Die Commit-Objekte zeichnen die für die Protokollnachricht verwendete Kodierung in ihrer Kodierung auf
Header; Diese Option kann verwendet werden, um den Befehl anzuweisen, die Commit-Log-Nachricht neu zu codieren
in der vom Benutzer bevorzugten Kodierung. Für Befehle, die keine Installationsbefehle sind, ist dies der Standardwert
UTF-8. Beachten Sie, dass wir, wenn ein Objekt behauptet, in X codiert zu sein, und wir in X ausgeben
gibt das Objekt wörtlich aus; Dies bedeutet, dass im Original ungültige Sequenzen vorhanden sind
commit kann in die Ausgabe kopiert werden.

--show-signatur
Überprüfen Sie die Gültigkeit eines signierten Commit-Objekts, indem Sie die Signatur an gpg --verify übergeben
und die Ausgabe anzeigen.

--relatives-Datum
Synonym für --date=relative.

--date=
Wirkt nur für Daten, die in einem für Menschen lesbaren Format angezeigt werden, z. B. bei der Verwendung
--hübsch. Die Konfigurationsvariable log.date legt einen Standardwert für das --date des Protokollbefehls fest
Möglichkeit. Standardmäßig werden Daten in der ursprünglichen Zeitzone angezeigt (entweder die Zeitzone des Committers oder).
des Autors). Wenn -local an das Format angehängt wird (z. B. iso-local), ist dies die lokale Datei des Benutzers
Stattdessen wird die Zeitzone verwendet.

--date=relative zeigt Datumsangaben relativ zur aktuellen Zeit an, z. B. „vor 2 Stunden“. Der
Die Option -local kann nicht mit --raw oder --relative verwendet werden.

--date=local ist ein Alias ​​für --date=default-local.

--date=iso (oder --date=iso8601) zeigt Zeitstempel in einem ISO 8601-ähnlichen Format an. Der
Unterschiede zum strengen ISO 8601-Format sind:

· ein Leerzeichen anstelle des T-Datums-/Uhrzeittrennzeichens

· ein Raum zwischen Zeit und Zeitzone

· Kein Doppelpunkt zwischen Stunden und Minuten der Zeitzone

--date=iso-strict (oder --date=iso8601-strict) zeigt Zeitstempel im strengen ISO 8601 an
Format.

--date=rfc (oder --date=rfc2822) zeigt Zeitstempel im RFC 2822-Format an, die häufig in zu finden sind
E-Mail-Nachrichten

--date=short zeigt nur das Datum, nicht aber die Uhrzeit im Format JJJJ-MM-TT an.

--date=raw zeigt das Datum im internen rohen Git-Format %s %z-Format an.

--date=format:... speist das Format ... in die strftime Ihres Systems ein. Verwenden Sie --date=format:%c
um das Datum im bevorzugten Format Ihres Systemgebietsschemas anzuzeigen. Weitere Informationen finden Sie im Strftime-Handbuch
eine vollständige Liste der Formatplatzhalter. Bei Verwendung von -local lautet die korrekte Syntax
--date=format-local:....

--date=default ist das Standardformat und ähnelt --date=rfc2822, mit einigen wenigen Ausnahmen
Ausnahmen:

· Nach dem Wochentag steht kein Komma

· Die Zeitzone wird weggelassen, wenn die lokale Zeitzone verwendet wird

--Header
Den Inhalt des Commits im Rohformat ausgeben; Jeder Datensatz wird durch ein NUL getrennt
Charakter.

--Eltern
Geben Sie auch die übergeordneten Elemente des Commits aus (in der Form „übergeordnetes Commit ...“). Ermöglicht auch
Übergeordnetes Umschreiben, siehe Geschichte Vereinfachung unten mit.

--Kinder
Geben Sie auch die untergeordneten Elemente des Commits aus (in der Form „commit child...“). Ermöglicht auch
Übergeordnetes Umschreiben, siehe Geschichte Vereinfachung unten mit.

--Zeitstempel
Drucken Sie den Roh-Commit-Zeitstempel.

--links rechts
Markieren Sie, von welcher Seite eines symmetrischen Diff aus ein Commit erreichbar ist. Commits von links
Seite wird ein < vorangestellt, diejenigen von rechts ein >. In Kombination mit --boundary,
Diesen Commits wird ein - vorangestellt.

Wenn Sie beispielsweise über diese Topologie verfügen:

y---b---b Zweig B
/ \ /
/.
/ /
o---x---a---ein Zweig A

Sie würden eine Ausgabe wie diese erhalten:

$ git rev-list --left-right --boundary --pretty=oneline A...B

>bbbbbbb... 3. auf b
>bbbbbbb... 2. auf b
<aaaaaaa... 3. auf a
<aaaaaaa... 2. auf a
-yyyyyyy... 1. auf b
-xxxxxxx... 1. auf a

--Graph
Zeichnen Sie auf der linken Seite eine textbasierte grafische Darstellung des Commit-Verlaufs
der Ausgabe. Dies kann dazu führen, dass zwischen den Commits der Reihe nach zusätzliche Zeilen gedruckt werden
damit der Diagrammverlauf ordnungsgemäß gezeichnet wird. Kann nicht mit --no-walk kombiniert werden.

Dies ermöglicht das Umschreiben der übergeordneten Elemente, siehe Geschichte Vereinfachung unten mit.

Dies impliziert standardmäßig die Option --topo-order, aber möglicherweise auch die Option --date-order
angegeben werden.

--show-linear-break[= ]
Wenn --graph nicht verwendet wird, werden alle Verlaufszweige abgeflacht, was dies erschweren kann
Beachten Sie, dass die beiden aufeinanderfolgenden Commits nicht zu einem linearen Zweig gehören. Diese Option
stellt in diesem Fall eine Barriere dazwischen. Wenn angegeben ist, ist es das
Zeichenfolge, die anstelle der Standardzeichenfolge angezeigt wird.

--zählen
Geben Sie eine Zahl aus, die angibt, wie viele Commits aufgelistet worden wären, und unterdrücken Sie alle anderen
Ausgabe. Bei Verwendung zusammen mit --left-right werden stattdessen die Zählwerte für links und ausgegeben
rechte Commits, getrennt durch einen Tab. Bei Verwendung zusammen mit --cherry-mark den Patch weglassen
Ermitteln Sie äquivalente Commits aus diesen Zählungen und geben Sie die Anzahl für äquivalente Commits aus
durch einen Tab getrennt.

PRETTY FORMATEN

Wenn es sich bei dem Commit um eine Zusammenführung handelt, beim Pretty-Format jedoch nicht eine Linie, E-Mail or roh, ein
Eine zusätzliche Zeile wird vor dem eingefügt Autor: Linie. Diese Zeile beginnt mit „Merge:“ und
Die SHA1s der Vorgänger-Commits werden durch Leerzeichen getrennt gedruckt. Beachten Sie, dass die aufgeführten
Commits müssen nicht unbedingt die Liste der sein direkt Eltern-Commits, wenn Sie eingeschränkt sind
Ihre Sicht auf die Geschichte: Wenn Sie beispielsweise nur an Änderungen im Zusammenhang mit a interessiert sind
bestimmtes Verzeichnis oder eine bestimmte Datei.

Es gibt mehrere integrierte Formate, und Sie können zusätzliche Formate definieren, indem Sie ein festlegen
hübsch. config-Option entweder auf einen anderen Formatnamen oder eine Format: Zeichenfolge, als
unten beschrieben (siehe git-config(1)). Hier sind die Details der integrierten Formate:

· eine Linie



Dieser ist so kompakt wie möglich konzipiert.

· kurz

begehen
Autor:



· mittlere

begehen
Autor:
Datum:





· voller

begehen
Autor:
Begehen:





· voller

begehen
Autor:
AutorDatum:
Begehen:
CommitDate:





· E-Mail

Aus
Aus:
Datum:
Betreff: [PATCH]



· roh

Der roh Das Format zeigt den gesamten Commit genau so an, wie er im Commit-Objekt gespeichert ist.
Insbesondere werden die SHA-1s vollständig angezeigt, unabhängig davon, ob --abbrev oder
--no-abbrev werden verwendet, und Eltern Informationen zeigen die wahren übergeordneten Commits, ohne
unter Berücksichtigung von Transplantaten oder Anamnesevereinfachungen. Beachten Sie, dass dieses Format Auswirkungen hat
die Art und Weise, wie Commits angezeigt werden, aber nicht die Art und Weise, wie der Unterschied angezeigt wird, z. B. mit Git Log
--roh. Um vollständige Objektnamen in einem rohen Diff-Format zu erhalten, verwenden Sie --no-abbrev.

· Format:

Der Format: Mit dem Format können Sie angeben, welche Informationen Sie anzeigen möchten.
Es funktioniert ein wenig wie das printf-Format, mit der bemerkenswerten Ausnahme, dass Sie ein erhalten
Zeilenumbruch mit %n statt \n.

Z.B, Format: „Die Autor of %h wurde %ein, %ar%nDie Titel wurde >>%s<<%n" würde zeigen
etwas wie das:

Der Autor von fe6e0ee war Junio ​​C Hamano, vor 23 Stunden
Der Titel war >>t4119: test autocomputing -p für traditionelle Diff-Eingabe.<

Die Platzhalter sind:

· %H: Hash festschreiben

· %h: abgekürzter Commit-Hash

· %T: Baum-Hash

· %t: abgekürzter Baum-Hash

· %P: Eltern-Hashes

· %p: abgekürzte Eltern-Hashes

· %ein: Autorenname

· %ein: Name des Autors (bezüglich .mailmap, siehe git-kurzlog(1) oder git-Schuld(1))

· %ae: E-Mail des Autors

· %aE: E-Mail des Autors (bezüglich .mailmap, siehe git-kurzlog(1) oder git-Schuld(1))

· %Anzeige: Autorendatum (Format berücksichtigt die Option --date=)

· %Anzeige: Autordatum, RFC2822-Stil

· %ar: Autorendatum, relativ

· %bei: Autorendatum, UNIX-Zeitstempel

· %ai: Autordatum, ISO 8601-ähnliches Format

· %aI: Autordatum, striktes ISO 8601-Format

· %cn: Name des Committers

· %cN: Name des Committers (in Bezug auf .mailmap, siehe git-kurzlog(1) oder git-Schuld(1))

· %ce: E-Mail des Committers

· %cE: E-Mail des Committers (bezüglich .mailmap, siehe git-kurzlog(1) oder git-Schuld(1))

· %CD: Committer-Datum (Format berücksichtigt die Option --date=)

· %CD: Committer-Datum, RFC2822-Stil

· %cr: Committer-Datum, relativ

· %ct: Committer-Datum, UNIX-Zeitstempel

· %ci: Committer-Datum, ISO 8601-ähnliches Format

· %cI: Committer-Datum, striktes ISO 8601-Format

· %d: Referenznamen, wie die Option --decorate von Git-Log(1)

· %D: Referenznamen ohne Umbruch „(“, „)“.

· %e: Kodierung

· %s: Thema

· %f: bereinigte Betreffzeile, geeignet für einen Dateinamen

· %b: Körper

· %B: roher Körper (ausgepacktes Subjekt und Körper)

· %GG: Rohbestätigungsnachricht von GPG für einen signierten Commit

· %G?: Zeige „G“ für eine gute Signatur, „B“ für eine schlechte Signatur, „U“ für eine gute,
nicht vertrauenswürdige Signatur und „N“ für keine Signatur

· %GS: Zeigt den Namen des Unterzeichners für einen signierten Commit an

· %GK: Zeigt den Schlüssel an, der zum Signieren eines signierten Commits verwendet wird

· %gD: Reflog-Selektor, z. B. refs/stash@{1}

· %gd: verkürzter Reflog-Selektor, z. B. stash@{1}

· %gn: Reflog-Identitätsname

· %gN: Reflog-Identitätsname (bezüglich .mailmap, siehe git-kurzlog(1) oder Git-
Schuld(1))

· %ge: Reflog-Identitäts-E-Mail

· %gE: Reflog-Identitäts-E-Mail (bezüglich .mailmap, siehe git-kurzlog(1) oder Git-
Schuld(1))

· %gs: Reflog-Betreff

· %Cred: Farbe auf Rot umstellen

· %Cgrün: Farbe auf Grün umstellen

· %Cblau: Farbe auf Blau umstellen

· %Creset: Farbe zurücksetzen

· %C(...): Farbspezifikation, wie in der Konfigurationsoption color.branch.* beschrieben; hinzufügen
Auto, zu Beginn wird nur dann Farbe ausgegeben, wenn Farben für die Protokollausgabe aktiviert sind
(durch color.diff, color.ui oder --color und unter Berücksichtigung der automatischen Einstellungen von
ersteres, wenn wir zu einem Terminal fahren). Nur Auto (dh %C(auto)) wird eingeschaltet
Automatische Einfärbung der nächsten Platzhalter, bis die Farbe erneut geändert wird.

· %m: links, rechts oder Grenzmarkierung

· %n: Neue Zeile

· %%: ein rohes %

· %x00: Ein Byte aus einem Hex-Code drucken

· %w([ [, [, ]]]): Zeilenumbruch ändern, wie die Option -w von Git-
Kurzprotokoll(1).

· %<( [,trunc|ltrunc|mtrunc]): Lassen Sie den nächsten Platzhalter mindestens N Spalten einnehmen,
Füllen Sie bei Bedarf Leerzeichen auf der rechten Seite aus. Optional am Anfang abschneiden
(ltrunc), die Mitte (mtrunc) oder das Ende (trunc), wenn die Ausgabe länger als N ist
Säulen. Beachten Sie, dass das Abschneiden nur bei N >= 2 korrekt funktioniert.

· %<|( ): Lassen Sie den nächsten Platzhalter mindestens bis zur N-ten Spalte dauern, Auffüllen
Leerzeichen auf der rechten Seite ggf. einfügen

· %>( ), %>|( ): ähnlich zu %<( ), %<|( ) bzw., aber Auffüllen von Leerzeichen
auf der Linken

· %>>( ), %>>|( ): ähnlich zu %>( ), %>|( ) jeweils, außer dass, wenn die
Der nächste Platzhalter benötigt mehr Leerzeichen als angegeben und links davon befinden sich Leerzeichen.
Nutzen Sie diese Räume

· %><( ), %><|( ): ähnlich zu % <( ), %<|( ) jeweils, aber beide auffüllen
Seiten (d. h. der Text ist zentriert)

Hinweis
Einige Platzhalter hängen möglicherweise von anderen Optionen ab, die der Revisions-Traversal-Engine zur Verfügung stehen.
Beispielsweise fügen die Reflog-Optionen %g* eine leere Zeichenfolge ein, es sei denn, dies ist der Fall
Durchlaufen von Reflog-Einträgen (z. B. mit git log -g). Die Platzhalter %d und %D werden verwendet
das „kurze“ Dekorationsformat, wenn --decorate nicht bereits im Befehl angegeben wurde
Linie.

Wenn Sie danach ein + (Pluszeichen) hinzufügen % eines Platzhalters wird sofort ein Zeilenvorschub eingefügt
vor der Erweiterung genau dann, wenn der Platzhalter zu einer nicht leeren Zeichenfolge erweitert wird.

Wenn Sie danach ein - (Minuszeichen) hinzufügen % eines Platzhalters, Zeilenvorschübe, die unmittelbar vorangehen
Die Erweiterung wird genau dann gelöscht, wenn der Platzhalter zu einer leeren Zeichenfolge erweitert wird.

Wenn Sie danach ein „“ (Leerzeichen) hinzufügen % Bei einem Platzhalter wird unmittelbar davor ein Leerzeichen eingefügt
die Erweiterung genau dann, wenn der Platzhalter zu einer nicht leeren Zeichenfolge erweitert wird.

· Format:

Der Format: Format funktioniert genau wie Format:, außer dass es „Terminator“ bereitstellt
Semantik statt „Trenner“-Semantik. Mit anderen Worten, jedes Commit hat das
Angehängtes Nachrichtenabschlusszeichen (normalerweise ein Zeilenumbruch) anstelle eines Trennzeichens
zwischen den Einträgen platziert. Dies bedeutet, dass der endgültige Eintrag ein einzeiliges Format hat
ordnungsgemäß mit einer neuen Zeile abgeschlossen werden, genau wie das „oneline“-Format. Für
Beispiel:

$ git log -2 --pretty=format:%h 4da45bef
| perl -pe '$_ .= " -- NO NEWLINE\n" es sei denn /\n/'
4da45be
7134973 – KEIN NEWLINE

$ git log -2 --pretty=tformat:%h 4da45bef
| perl -pe '$_ .= " -- NO NEWLINE\n" es sei denn /\n/'
4da45be
7134973

Darüber hinaus wird jede unbekannte Zeichenfolge, die ein % enthält, so interpretiert, als ob dies der Fall wäre
tformat: davor. Diese beiden sind beispielsweise gleichwertig:

$ git log -2 --pretty=tformat:%h 4da45bef
$ git log -2 --pretty=%h 4da45bef

GIT

Ein Teil des git(1) Suite

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