Git

git-log zuletzt aktualisiert in 2.52.0

NAME

git-log - Commit-Logs anzeigen

SYNOPSIS

git log [<options>] [<revision-range>] [[--] <path>…]

BESCHREIBUNG

Zeigt die Commit-Logs an.

Listet Commits auf, die durch das Folgen der parent Links vom gegebenen Commit (oder den gegebenen Commits) erreichbar sind, schließt jedoch Commits aus, die von denjenigen erreichbar sind, die mit einem ^ davor angegeben wurden. Die Ausgabe erfolgt standardmäßig in umgekehrter chronologischer Reihenfolge.

Man kann sich dies als eine Mengenoperation vorstellen. Commits, die von einem der auf der Kommandozeile angegebenen Commits erreichbar sind, bilden eine Menge. Davon werden dann die Commits subtrahiert, die von einem der mit einem ^ davor angegebenen Commits erreichbar sind. Die verbleibenden Commits sind das, was in der Ausgabe des Befehls erscheint. Verschiedene andere Optionen und Pfadparameter können verwendet werden, um das Ergebnis weiter einzuschränken.

Daher bedeutet der folgende Befehl

$ git log foo bar ^baz

"liste alle Commits, die von foo oder bar erreichbar sind, aber nicht von baz".

Eine spezielle Notation "<commit1>..<commit2>" kann als Kurzschreibweise für "^<commit1> <commit2>" verwendet werden. Zum Beispiel können die folgenden entweder austauschbar verwendet werden

$ git log origin..HEAD
$ git log HEAD ^origin

Eine weitere spezielle Notation ist "<commit1>...<commit2>", die für Merges nützlich ist. Die resultierende Menge von Commits ist die symmetrische Differenz zwischen den beiden Operanden. Die folgenden zwei Befehle sind äquivalent

$ git log A B --not $(git merge-base --all A B)
$ git log A...B

Der Befehl nimmt Optionen entgegen, die auf den Befehl git-rev-list[1] anwendbar sind, um zu steuern, was und wie angezeigt wird, sowie Optionen, die auf den Befehl git-diff[1] anwendbar sind, um zu steuern, wie die Änderungen angezeigt werden, die jeder Commit einführt.

OPTIONEN

--follow

Listet die Historie einer Datei über Umbenennungen hinaus fort (funktioniert nur für eine einzelne Datei).

--no-decorate

--decorate[=(short|full|auto|no)]

Gibt die Ref-Namen aller angezeigten Commits aus. Mögliche Werte sind

`short`;; the ref name prefixes `refs/heads/`, `refs/tags/` and
	`refs/remotes/` are not printed.
`full`;; the full ref name (including prefix) is printed.
`auto`:: if the output is going to a terminal, the ref names
	are shown as if `short` were given, otherwise no ref names are
	shown.

Die Option --decorate ist eine Kurzform für --decorate=short. Standardmäßig wird der Konfigurationswert von log.decorate verwendet, falls konfiguriert, andernfalls auto.

--decorate-refs=<Muster>

--decorate-refs-exclude=<Muster>

Für jede Kandidatenreferenz wird sie nicht zur Dekoration verwendet, wenn sie einem der für --decorate-refs-exclude angegebenen <Muster> entspricht oder wenn sie keinem der für --decorate-refs angegebenen <Muster> entspricht. Die Konfigurationsoption log.excludeDecoration erlaubt das Ausschließen von Refs von den Dekorationen, aber ein explizites --decorate-refs-Muster überschreibt eine Übereinstimmung in log.excludeDecoration.

Wenn keine dieser Optionen oder Konfigurationseinstellungen gegeben sind, dann werden Referenzen als Dekoration verwendet, wenn sie HEAD, refs/heads/, refs/remotes/, refs/stash/ oder refs/tags/ entsprechen.

--clear-decorations

Wenn diese Option angegeben wird, werden alle vorherigen --decorate-refs- oder --decorate-refs-exclude-Optionen gelöscht und der Standardfilter für Dekorationen wird gelockert, um alle Referenzen einzuschließen. Diese Option wird angenommen, wenn der Konfigurationswert log.initialDecorationSet auf all gesetzt ist.

--source

Gibt den auf der Kommandozeile angegebenen Ref-Namen aus, über den jeder Commit erreicht wurde.

--mailmap

--no-mailmap

--use-mailmap

--no-use-mailmap

Verwendet die Mailmap-Datei, um Autoren- und Committer-Namen und E-Mail-Adressen auf kanonische Realnamen und E-Mail-Adressen abzubilden. Siehe git-shortlog[1].

--full-diff

Ohne dieses Flag zeigt git log -p <pfad>... Commits an, die die angegebenen Pfade berühren, und Diffs zu denselben angegebenen Pfaden. Mit diesem Flag wird der vollständige Diff für Commits angezeigt, die die angegebenen Pfade berühren; das bedeutet, dass "<pfad>..." nur die Commits einschränkt und nicht den Diff für diese Commits einschränkt.

Beachten Sie, dass dies alle diff-basierten Ausgabetypen beeinflusst, z. B. die, die von --stat usw. erzeugt werden.

--log-size

Fügt für jeden Commit eine Zeile log size <anzahl> in die Ausgabe ein, wobei <anzahl> die Länge der Nachricht dieses Commits in Bytes ist. Dies soll Tools beschleunigen, die Log-Nachrichten aus der Ausgabe von git log lesen, indem ihnen ermöglicht wird, Speicher im Voraus zuzuweisen.

-L<start>,<end>:<datei>

-L:<funktionsname>:<datei>

Verfolgt die Entwicklung des Zeilenbereichs, der durch <start>,<end> oder durch den Funktionsnamen-Regex <funcname> innerhalb der <datei> gegeben ist. Sie dürfen keine Pfadspezifikationen angeben. Dies ist derzeit auf einen Walk beschränkt, der von einer einzelnen Revision ausgeht, d.h. Sie dürfen nur null oder ein positives Revisionsargument angeben und <start> und <end> (oder <funcname>) müssen in der Startrevision vorhanden sein. Sie können diese Option mehrfach angeben. Impliziert --patch. Die Patch-Ausgabe kann mit --no-patch unterdrückt werden, aber andere Diff-Formate (nämlich --raw, --numstat, --shortstat, --dirstat, --summary, --name-only, --name-status, --check) sind derzeit nicht implementiert.

<Start> und <Ende> können eine der folgenden Formen annehmen:

<Nummer>

Wenn <Start> oder <Ende> eine Zahl ist, gibt sie eine absolute Zeilennummer an (Zeilen werden ab 1 gezählt).
/<Regulärer Ausdruck>/

Diese Form verwendet die erste Zeile, die dem gegebenen POSIX-<Regulärer Ausdruck> entspricht. Wenn <Start> ein regulärer Ausdruck ist, wird vom Ende des vorherigen -L-Bereichs, falls vorhanden, ansonsten vom Anfang der Datei gesucht. Wenn <Start> ^/<Regulärer Ausdruck>/ ist, wird vom Anfang der Datei gesucht. Wenn <Ende> ein regulärer Ausdruck ist, wird ab der von <Start> angegebenen Zeile gesucht.
+<Offset> oder -<Offset>

Dies ist nur für <Ende> gültig und gibt eine Anzahl von Zeilen vor oder nach der von <Start> angegebenen Zeile an.

Wenn :<Funktionsname> anstelle von <Start> und <Ende> angegeben ist, ist dies ein regulärer Ausdruck, der den Bereich vom ersten Funktionsnamen-Zeile, der <Funktionsname> entspricht, bis zur nächsten Funktionsnamen-Zeile bezeichnet. :<Funktionsname> sucht vom Ende des vorherigen -L-Bereichs, falls vorhanden, ansonsten vom Anfang der Datei. ^:<Funktionsname> sucht vom Anfang der Datei. Die Funktionsnamen werden auf die gleiche Weise bestimmt wie git diff Hunk-Header ermittelt (siehe Defining a custom hunk-header in gitattributes[5]).

<revisionsbereich>

Zeigt nur Commits im angegebenen Revisionsbereich an. Wenn kein <revisionsbereich> angegeben ist, wird standardmäßig HEAD verwendet (d.h. die gesamte Historie, die zum aktuellen Commit führt). origin..HEAD gibt alle Commits an, die vom aktuellen Commit (d.h. HEAD) erreichbar sind, aber nicht von origin. Eine vollständige Liste der Möglichkeiten, <revisionsbereich> zu schreiben, finden Sie im Abschnitt Specifying Ranges in gitrevisions[7].

[--] <pfad>...

Zeigt nur Commits an, die ausreichen, um zu erklären, wie die Dateien, die mit den angegebenen Pfaden übereinstimmen, entstanden sind. Siehe History Simplification unten für Details und andere Vereinfachungsmodi.

Pfade müssen möglicherweise mit -- vorangestellt werden, um sie von Optionen oder dem Revisionsbereich zu trennen, wenn Verwirrung entsteht.

Commit-Limitierung

Zusätzlich zur Angabe eines Commit-Bereichs, der mithilfe der speziellen Notationen, die in der Beschreibung erläutert werden, aufgelistet werden soll, können weitere Commit-Limitierungen angewendet werden.

Die Verwendung von mehr Optionen beschränkt in der Regel die Ausgabe weiter (z. B. beschränkt --since=<date1> auf neuere Commits als <date1>, und die Verwendung mit --grep=<pattern> schränkt weiter auf Commits ein, deren Log-Nachricht eine Zeile enthält, die <pattern> entspricht), sofern nicht anders angegeben.

Beachten Sie, dass diese Optionen vor Commit-Sortier- und Formatierungsoptionen wie --reverse angewendet werden.

-<anzahl>

-n <anzahl>

--max-count=<anzahl>

Begrenzt die Ausgabe auf <number> Commits.

--skip=<anzahl>

Überspringt <number> Commits, bevor die Commit-Ausgabe angezeigt wird.

--since=<datum>

--after=<datum>

Zeigt Commits neuer als <date> an.

--since-as-filter=<datum>

Zeigt alle Commits neuer als <date> an. Dabei werden alle Commits im Bereich durchlaufen, anstatt beim ersten Commit anzuhalten, der älter als <date> ist.

--until=<datum>

--before=<datum>

Zeigt Commits älter als <date> an.

--author=<muster>

--committer=<muster>

Beschränkt die Ausgabe von Commits auf solche, deren Autor-/Committer-Headerzeilen dem regulären Ausdruck <pattern> entsprechen. Bei mehr als einem --author=<pattern> werden Commits ausgewählt, deren Autor eines der <pattern> erfüllt (ähnlich für mehrere --committer=<pattern>).

--grep-reflog=<muster>

Beschränkt die Ausgabe von Commits auf solche mit Reflog-Einträgen, die dem regulären Ausdruck <pattern> entsprechen. Bei mehr als einem --grep-reflog werden Commits ausgewählt, deren Reflog-Nachricht einem der angegebenen Muster entspricht. Es ist ein Fehler, diese Option zu verwenden, es sei denn, --walk-reflogs wird verwendet.

--grep=<muster>

Beschränkt die Ausgabe von Commits auf solche mit einer Log-Nachricht, die dem regulären Ausdruck <pattern> entspricht. Bei mehr als einem --grep=<pattern> werden Commits ausgewählt, deren Nachricht einem der <pattern> entspricht (aber siehe --all-match).

Wenn --notes aktiv ist, wird die Nachricht aus den Notizen so abgeglichen, als wäre sie Teil der Log-Nachricht.

--all-match

Beschränkt die Ausgabe von Commits auf solche, die allen angegebenen --grep-Mustern entsprechen, anstatt solchen, die mindestens einem entsprechen.

--invert-grep

Beschränkt die Ausgabe von Commits auf solche mit einer Log-Nachricht, die nicht dem mit --grep=<pattern> angegebenen <pattern> entsprechen.

-i

--regexp-ignore-case

Gleicht die regulären Ausdrucksmuster für die Beschränkung ohne Berücksichtigung der Groß- und Kleinschreibung ab.

--basic-regexp

Betrachtet die Muster für die Beschränkung als grundlegende reguläre Ausdrücke; dies ist der Standard.

-E

--extended-regexp

Betrachtet die Muster für die Beschränkung als erweiterte reguläre Ausdrücke anstelle der standardmäßigen grundlegenden regulären Ausdrücke.

-F

--fixed-strings

Betrachtet die Muster für die Beschränkung als feste Zeichenketten (interpretiert Muster nicht als regulären Ausdruck).

-P

--perl-regexp

Betrachtet die Muster für die Beschränkung als Perl-kompatible reguläre Ausdrücke.

Die Unterstützung für diese Arten von regulären Ausdrücken ist eine optionale Abhängigkeit zur Kompilierzeit. Wenn Git nicht mit Unterstützung dafür kompiliert wurde, führt die Bereitstellung dieser Option zum Abbruch.

--remove-empty

Stoppt, wenn ein bestimmter Pfad aus dem Baum verschwindet.

--merges

Gibt nur Merge-Commits aus. Dies ist exakt dasselbe wie --min-parents=2.

--no-merges

Gibt keine Commits mit mehr als einem Elternteil aus. Dies ist exakt dasselbe wie --max-parents=1.

--min-parents=<anzahl>

--max-parents=<anzahl>

--no-min-parents

--no-max-parents

Zeigt nur Commits an, die mindestens (oder höchstens) so viele Eltern-Commits haben. Insbesondere ist --max-parents=1 dasselbe wie --no-merges, --min-parents=2 ist dasselbe wie --merges. --max-parents=0 gibt alle Wurzel-Commits und --min-parents=3 alle Octopus-Merges aus.

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

--first-parent

Bei der Suche nach einzubeziehenden Commits wird nur dem ersten Eltern-Commit gefolgt, wenn ein Merge-Commit angetroffen wird. Diese Option kann eine bessere Übersicht beim Betrachten der Entwicklung eines bestimmten Topic-Branches geben, da Merges in einen Topic-Branch tendenziell nur dazu dienen, von Zeit zu Zeit mit dem aktualisierten Upstream synchron zu werden. Diese Option erlaubt es Ihnen, die einzelnen Commits zu ignorieren, die durch einen solchen Merge in Ihre Historie gebracht wurden.

Diese Option ändert auch das Standard-Diff-Format für Merge-Commits auf first-parent, siehe --diff-merges=first-parent für Details.

--exclude-first-parent-only

Bei der Suche nach auszuschließenden Commits (mit einem ^) wird nur dem ersten Eltern-Commit gefolgt, wenn ein Merge-Commit angetroffen wird. Dies kann verwendet werden, um die Menge der Änderungen in einem Topic-Branch ab dem Punkt zu finden, an dem er sich vom Remote-Branch abzweigte, vorausgesetzt, beliebige Merges können gültige Topic-Branch-Änderungen sein.

--not

Kehrt die Bedeutung des Präfixes ^ (oder des Fehlens davon) für alle folgenden Revisionsspezifizierer um, bis zum nächsten --not. Wenn es auf der Kommandozeile vor --stdin verwendet wird, werden die über stdin übergebenen Revisionen nicht davon beeinflusst. Umgekehrt werden, wenn es über die Standardeingabe übergeben wird, die auf der Kommandozeile übergebenen Revisionen nicht davon beeinflusst.

--all

Verhält sich so, als ob alle Refs in refs/ zusammen mit HEAD auf der Kommandozeile als <commit> aufgelistet wären.

--branches[=<muster>]

Verhält sich so, als ob alle Refs in refs/heads auf der Kommandozeile als <commit> aufgelistet wären. Wenn <pattern> angegeben ist, werden die Branches auf diejenigen beschränkt, die dem angegebenen Shell-Glob-Muster entsprechen. Wenn <pattern> keine ?, * oder [ enthält, wird am Ende /* angenommen.

--tags[=<muster>]

Verhält sich so, als ob alle Refs in refs/tags auf der Kommandozeile als <commit> aufgelistet wären. Wenn <pattern> angegeben ist, werden die Tags auf diejenigen beschränkt, die dem angegebenen Shell-Glob-Muster entsprechen. Wenn das Muster keine ?, * oder [ enthält, wird am Ende /* angenommen.

--remotes[=<muster>]

Verhält sich so, als ob alle Refs in refs/remotes auf der Kommandozeile als <commit> aufgelistet wären. Wenn <pattern> angegeben ist, werden die Remote-Tracking-Branches auf diejenigen beschränkt, die dem angegebenen Shell-Glob-Muster entsprechen. Wenn das Muster keine ?, * oder [ enthält, wird am Ende /* angenommen.

--glob=<glob-muster>

Verhält sich so, als ob alle Refs, die dem Shell-Glob-Muster <glob-pattern> entsprechen, auf der Kommandozeile als <commit> aufgelistet wären. Wenn das Präfix refs/ fehlt, wird es automatisch hinzugefügt. Wenn das Muster keine ?, * oder [ enthält, wird am Ende /* angenommen.

--exclude=<glob-muster>

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.

--reflog

Verhält sich so, als ob alle von Reflogs referenzierten Objekte auf der Kommandozeile als <commit> aufgelistet wären.

--alternate-refs

Verhält sich so, als ob alle Objekte, die als Ref-Spitzen von alternativen Repositories referenziert werden, auf der Kommandozeile aufgelistet wären. Ein alternatives Repository ist jedes Repository, dessen Objektverzeichnis in objects/info/alternates angegeben ist. Die Menge der eingeschlossenen Objekte kann durch core.alternateRefsCommand usw. modifiziert werden. Siehe git-config[1].

--single-worktree

Standardmäßig werden alle Arbeitsbäume von den folgenden Optionen untersucht, wenn mehr als einer vorhanden ist (siehe git-worktree[1]): --all, --reflog und --indexed-objects. Diese Option zwingt sie, nur den aktuellen Arbeitsbaum zu untersuchen.

--ignore-missing

Beim Ansehen eines ungültigen Objektnamens in der Eingabe, verhalten Sie sich so, als wäre die fehlerhafte Eingabe nicht gegeben worden.

--bisect

Verhält sich so, als ob die fehlerhafte Bisection-Ref refs/bisect/bad aufgelistet worden wäre und als ob darauf --not und die guten Bisection-Refs refs/bisect/good-* auf der Kommandozeile gefolgt wären.

--stdin

Zusätzlich zum Empfangen von Argumenten von der Kommandozeile werden diese auch von der Standardeingabe gelesen. Dies akzeptiert Commits und Pseudo-Optionen wie --all und --glob=. Wenn ein Trennzeichen -- gesehen wird, wird die folgende Eingabe als Pfade behandelt und zur Begrenzung des Ergebnisses verwendet. Flags wie --not, die über die Standardeingabe gelesen werden, werden nur für die auf die gleiche Weise übergebenen Argumente berücksichtigt und beeinflussen keine nachfolgenden Kommandozeilenargumente.

--cherry-mark

Ähnlich wie --cherry-pick (siehe unten), aber gleichwertige Commits werden mit = markiert anstatt weggelassen zu werden, und ungleichwertige mit +.

--cherry-pick

Lässt jeden Commit aus, der dieselbe Änderung wie ein anderer Commit auf der "anderen Seite" einführt, wenn die Menge der Commits durch symmetrische Differenz begrenzt wird.

Wenn Sie beispielsweise zwei Branches, A und B, haben, ist eine übliche Methode, alle Commits auf nur einer Seite davon aufzulisten, --left-right (siehe das Beispiel unten in der Beschreibung der --left-right Option). Allerdings werden die Commits angezeigt, die von dem anderen Branch cherry-picked wurden (z. B. "3rd on b" könnte von Branch A cherry-picked worden sein). Mit dieser Option werden solche Commit-Paare von der Ausgabe ausgeschlossen.

--left-only

--right-only

Listet nur Commits auf der jeweiligen Seite einer symmetrischen Differenz auf, d. h. nur diejenigen, die von --left-right als < bzw. > markiert würden.

Zum Beispiel lässt --cherry-pick --right-only A...B jene Commits aus B aus, die in A enthalten sind oder Patch-Äquivalente zu einem Commit in A haben. Mit anderen Worten, dies listet die + Commits aus git cherry A B auf. Genauer gesagt, --cherry-pick --right-only --no-merges liefert die exakte Liste.

--cherry

Ein Synonym für --right-only --cherry-mark --no-merges; nützlich, um die Ausgabe auf die Commits auf unserer Seite zu beschränken und diejenigen zu markieren, die auf der anderen Seite einer verzweigten Historie angewendet wurden, mit git log --cherry upstream...mybranch, ähnlich wie bei git cherry upstream mybranch.

-g

--walk-reflogs

Anstatt die Commit-Abstammungskette zu durchlaufen, werden die Reflog-Einträge von den neuesten zu den älteren durchlaufen. Wenn diese Option verwendet wird, können keine Commits zum Ausschluss angegeben werden (d.h. die Notationen ^<commit>, <commit1>..<commit2> und <commit1>...<commit2> können nicht verwendet werden).

Mit einem --pretty-Format außer oneline und reference (aus offensichtlichen Gründen) führt dies dazu, dass die Ausgabe zwei zusätzliche Zeilen mit Informationen aus dem Reflog enthält. Der Reflog-Deskriptor in der Ausgabe kann als ref@{<Nth>} (wobei <Nth> der reverse-chronologische Index im Reflog ist) oder als ref@{<timestamp>} (mit dem <timestamp> für diesen Eintrag) angezeigt werden, abhängig von einigen Regeln.

Wenn der Startpunkt als ref@{<Nth>} angegeben ist, wird das Indexformat angezeigt.
Wenn der Startpunkt als ref@{now} angegeben war, wird das Zeitstempelformat angezeigt.
Wenn keiner von beiden verwendet wurde, aber --date auf der Kommandozeile angegeben wurde, wird der Zeitstempel im angeforderten Format von --date angezeigt.
Andernfalls wird das Indexformat angezeigt.

Unter --pretty=oneline wird die Commit-Nachricht mit diesen Informationen auf derselben Zeile vorangestellt. Diese Option kann nicht mit --reverse kombiniert werden. Siehe auch git-reflog[1].

Unter --pretty=reference werden diese Informationen überhaupt nicht angezeigt.

--merge

Zeigt Commits an, die sich mit widersprüchlichen Pfaden im Bereich HEAD...<other> befassen, wobei <other> die erste existierende Pseudoref in MERGE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD oder REBASE_HEAD ist. Funktioniert nur, wenn der Index ungelöste Einträge aufweist. Diese Option kann verwendet werden, um relevante Commits anzuzeigen, wenn Konflikte aus einem 3-Wege-Merge gelöst werden.

--boundary

Gibt ausgeschlossene Grenzmeldungen aus. Grenzmeldungen werden mit - vorangestellt.

Verlauf vereinfachung

Manchmal interessieren Sie sich nur für Teile des Verlaufs, zum Beispiel die Commits, die einen bestimmten <path> ändern. Aber es gibt zwei Teile der Verlauf vereinfachung, ein Teil ist die Auswahl der Commits und der andere ist die Art und Weise, wie dies geschieht, da es verschiedene Strategien zur Vereinfachung des Verlaufs gibt.

Die folgenden Optionen wählen die anzuzeigenden Commits aus

<pfade>: Commits, die die angegebenen <paths> ändern, werden ausgewählt.
--simplify-by-decoration: Commits, die von einem Branch oder Tag referenziert werden, werden ausgewählt.

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

Standard Modus: Vereinfacht die Historie zur einfachsten Historie, die den Endzustand des Baums erklärt. Am einfachsten, weil sie einige Nebenäste beschneidet, wenn das Endergebnis dasselbe ist (d. h. Zweige mit demselben Inhalt zusammenführt).
--show-pulls: Schließt alle Commits vom Standardmodus ein, aber auch alle Merge-Commits, die NICHT TREESAME zum ersten Elternteil sind, aber TREESAME zu einem späteren Elternteil sind. Dieser Modus ist hilfreich, um die Merge-Commits anzuzeigen, die eine Änderung "erstmals" in einen Branch "eingeführt" haben.
--full-history: Dasselbe wie der Standardmodus, schneidet jedoch keine Historie ab.
--dense: Nur die ausgewählten Commits werden angezeigt, plus einige, um eine aussagekräftige Historie zu haben.
--sparse: Alle Commits in der vereinfachten Historie werden angezeigt.
--simplify-merges: Zusätzliche Option zu --full-history, um einige unnötige Merges aus der resultierenden Historie zu entfernen, da keine ausgewählten Commits zu diesem Merge beitragen.
--ancestry-path[=<commit>]: Wenn ein Bereich von Commits zum Anzeigen angegeben wird (z. B. <commit1>..<commit2> oder <commit2> ^<commit1>) und ein Commit <commit> in diesem Bereich, werden nur Commits in diesem Bereich angezeigt, die Vorfahren von <commit>, Nachkommen von <commit> oder <commit> selbst sind. Wenn kein Commit angegeben ist, wird <commit1> (der ausgeschlossene Teil des Bereichs) als <commit> verwendet. Kann mehrmals übergeben werden; in diesem Fall wird ein Commit einbezogen, wenn er einer der angegebenen Commits ist oder wenn er ein Vorfahre oder Nachkomme davon ist.

Eine detailliertere Erklärung folgt.

Angenommen, Sie haben foo als <paths> angegeben. Wir nennen Commits, die foo modifizieren, !TREESAME und die übrigen TREESAME. (In einem für foo gefilterten Diff sehen sie unterschiedlich und gleich aus, bzw.)

Im Folgenden werden wir immer denselben Beispielverlauf verwenden, um die Unterschiede zwischen den Vereinfachungseinstellungen zu veranschaulichen. Wir gehen davon aus, dass Sie für eine Datei foo in diesem Commit-Graphen filtern.

	  .-A---M---N---O---P---Q
	 /     /   /   /   /   /
	I     B   C   D   E   Y
	 \   /   /   /   /   /
	  `-------------'   X

Die horizontale Historienlinie A---Q wird als erster Elternteil jedes Merges betrachtet. Die Commits sind:

I ist der initiale Commit, in dem foo mit dem Inhalt asdf existiert und eine Datei quux mit dem Inhalt quux existiert. Initiale Commits werden mit einem leeren Baum verglichen, daher ist I !TREESAME.
In A enthält foo nur foo.
B enthält dieselbe Änderung wie A. Sein Merge M ist trivial und daher TREESAME zu allen Elternteilen.
C ändert foo nicht, aber sein Merge N ändert es zu foobar, daher ist es nicht TREESAME zu irgendeinem Elternteil.
D setzt foo auf baz. Sein Merge O kombiniert die Zeichenketten von N und D zu foobarbaz; d. h. er ist nicht TREESAME zu irgendeinem Elternteil.
E ändert quux zu xyzzy und sein Merge P kombiniert die Zeichenketten zu quux xyzzy. P ist TREESAME zu O, aber nicht zu E.
X ist ein unabhängiger Root-Commit, der eine neue Datei side hinzugefügt hat, und Y hat sie modifiziert. Y ist TREESAME zu X. Sein Merge Q fügt side zu P hinzu, und Q ist TREESAME zu P, aber nicht zu Y.

rev-list durchläuft die Historie rückwärts und schließt Commits ein oder schließt sie aus, je nachdem, ob --full-history und/oder Elternteil-Rewriting (über --parents oder --children) verwendet werden. Die folgenden Einstellungen sind verfügbar.

Standardmodus

Commits werden einbezogen, wenn sie NICHT TREESAME zu irgendeinem Elternteil sind (obwohl dies geändert werden kann, siehe --sparse unten). Wenn der Commit ein Merge war und er TREESAME zu einem Elternteil war, folgen Sie nur diesem Elternteil. (Auch wenn es mehrere TREESAME-Elternteile gibt, folgen Sie nur einem davon.) Andernfalls folgen Sie allen Elternteilen.

Dies führt zu

	  .-A---N---O
	 /     /   /
	I---------D

Beachten Sie, wie die Regel, nur dem TREESAME-Elternteil zu folgen, falls einer verfügbar ist, B vollständig aus der Betrachtung entfernt hat. C wurde über N berücksichtigt, ist aber TREESAME. Root-Commits werden mit einem leeren Baum verglichen, daher ist I !TREESAME.

Eltern-/Kind-Beziehungen sind nur mit --parents sichtbar, aber das beeinflusst nicht die im Standardmodus ausgewählten Commits, daher haben wir die Elternlinien gezeigt.

--full-history ohne Umwandlung der Eltern

Dieser Modus unterscheidet sich vom Standard in einem Punkt: Folgen Sie immer allen Elternteilen eines Merges, auch wenn er TREESAME zu einem davon ist. Selbst wenn mehr als eine Seite des Merges Commits enthält, die einbezogen werden, bedeutet dies nicht, dass der Merge selbst einbezogen wird! Im Beispiel erhalten wir

	I  A  B  N  D  O  P  Q

M wurde ausgeschlossen, weil er TREESAME zu beiden Elternteilen ist. E, C und B wurden alle durchlaufen, aber nur B war !TREESAME, daher erscheinen die anderen nicht.

Beachten Sie, dass es ohne Elternteil-Rewriting nicht wirklich möglich ist, über die Eltern-/Kind-Beziehungen zwischen den Commits zu sprechen, daher zeigen wir sie getrennt.

--full-history mit Umwandlung der Eltern

Gewöhnliche Commits werden nur dann einbezogen, wenn sie !TREESAME sind (obwohl dies geändert werden kann, siehe --sparse unten).

Merges werden immer einbezogen. Ihre Elternliste wird jedoch neu geschrieben: Entlang jedes Elternteils werden Commits, die selbst nicht einbezogen werden, entfernt. Dies führt zu

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

Vergleichen Sie mit --full-history ohne Rewriting oben. Beachten Sie, dass E entfernt wurde, weil es TREESAME ist, aber die Elternliste von P wurde so neu geschrieben, dass sie Es Elternteil I enthält. Dasselbe geschah für C und N sowie für X, Y und Q.

Zusätzlich zu den obigen Einstellungen können Sie ändern, ob TREESAME die Einbeziehung beeinflusst.

--dense

Durchlaufene Commits werden einbezogen, wenn sie NICHT TREESAME zu irgendeinem Elternteil sind.

--sparse

Alle durchlaufenen Commits werden einbezogen.

Beachten Sie, dass dies ohne --full-history immer noch Merges vereinfacht: Wenn einer der Elternteile TREESAME ist, folgen wir nur diesem, sodass die anderen Seiten des Merges niemals durchlaufen werden.

--simplify-merges

Bauen Sie zuerst einen Historien-Graphen auf, auf die gleiche Weise, wie --full-history mit Elternteil-Rewriting es tut (siehe oben).

Vereinfachen Sie dann jeden Commit C zu seinem Ersatz C' in der endgültigen Historie gemäß den folgenden Regeln:

Setzen Sie C' auf C.
Ersetzen Sie jeden Elternteil P von C' durch seine Vereinfachung P'. Dabei werden Elternteile, die Vorfahren anderer Elternteile sind oder die Root-Commits sind, die TREESAME zu einem leeren Baum sind, verworfen und Duplikate entfernt, aber darauf geachtet, nie alle Elternteile zu verwerfen, zu denen wir TREESAME sind.
Wenn nach diesem Elternteil-Rewriting C' ein Root- oder Merge-Commit ist (null oder mehr als 1 Elternteil hat), ein Rand-Commit ist oder !TREESAME ist, bleibt er bestehen. Andernfalls wird er durch seinen einzigen Elternteil ersetzt.

Die Auswirkung hiervon wird am besten durch den Vergleich mit --full-history mit Elternteil-Rewriting gezeigt. Das Beispiel wird zu

	  .-A---M---N---O
	 /     /       /
	I     B       D
	 \   /       /
	  `---------'

Beachten Sie die wesentlichen Unterschiede bei N, P und Q im Vergleich zu --full-history.

Ns Elternliste enthielt I, das entfernt wurde, da es ein Vorfahre des anderen Elternteils M ist. Dennoch blieb N bestehen, da es !TREESAME ist.
Ps Elternliste hatte ebenfalls I, das entfernt wurde. P wurde dann vollständig entfernt, da es einen Elternteil hatte und TREESAME war.
Qs Elternliste hatte Y vereinfacht zu X. X wurde dann entfernt, da es ein TREESAME-Root war. Q wurde dann vollständig entfernt, da es einen Elternteil hatte und TREESAME war.

Es gibt einen weiteren verfügbaren Vereinfachungsmodus.

--ancestry-path[=<commit>]

Beschränkt die angezeigten Commits auf solche, die Vorfahren von <commit> sind, oder die Nachkommen von <commit> sind, oder <commit> selbst sind.

Betrachten wir als Beispiel für die Anwendung die folgende Commit-Historie.

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

Ein normales D..M berechnet die Menge der Commits, die Vorfahren von M sind, schließt aber die aus, die Vorfahren von D sind. Dies ist nützlich, um zu sehen, was mit der Historie geschehen ist, die zu M führt, seit D existiert, im Sinne von "was hat M, das in D nicht existierte?". Das Ergebnis in diesem Beispiel wären alle Commits, außer A und B (und natürlich D selbst).

Wenn wir herausfinden wollen, welche Commits in M mit dem von D eingeführten Fehler kontaminiert sind und behoben werden müssen, möchten wir vielleicht nur die Teilmenge von D..M betrachten, die tatsächlich Nachkommen von D sind, d.h. C und K ausschließen. Genau das leistet die Option --ancestry-path. Angenommen auf den Bereich D..M, führt dies zu

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

Wir können auch --ancestry-path=D anstelle von --ancestry-path verwenden, was im Kontext des Bereichs D..M dasselbe bedeutet, aber nur expliziter ist.

Wenn wir stattdessen an einem bestimmten Thema innerhalb dieses Bereichs und allen davon betroffenen Commits interessiert sind, möchten wir vielleicht nur die Teilmenge von D..M betrachten, die dieses Thema in ihrem Vorfahrenpfad enthalten. So würde zum Beispiel die Verwendung von --ancestry-path=H D..M zu

		E
		 \
	      C---G---H---I---J
			       \
				L--M

während --ancestry-path=K D..M zu

		K---------------L--M

Bevor wir eine weitere Option, --show-pulls, besprechen, müssen wir ein neues Beispiel-Historie erstellen.

Ein häufiges Problem, mit dem Benutzer konfrontiert sind, wenn sie sich eine vereinfachte Historie ansehen, ist, dass ein Commit, von dem sie wissen, dass er eine Datei irgendwie geändert hat, in der vereinfachten Historie dieser Datei nicht erscheint. Lassen Sie uns ein neues Beispiel demonstrieren und zeigen, wie Optionen wie --full-history und --simplify-merges in diesem Fall funktionieren.

	  .-A---M-----C--N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`-Z'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `---Y--'

Für dieses Beispiel nehmen wir an, dass ich file.txt erstellt habe, das von A, B und X auf unterschiedliche Weise geändert wurde. Die Single-Parent-Commits C, Z und Y ändern file.txt nicht. Der Merge-Commit M wurde durch Auflösung eines Merge-Konflikts erstellt, um sowohl Änderungen von A als auch von B einzuschließen, und ist daher keiner von beiden TREESAME. Der Merge-Commit R wurde jedoch erstellt, indem der Inhalt von file.txt in M ignoriert und nur der Inhalt von file.txt in X übernommen wurde. Daher ist R TREESAME zu X, aber nicht zu M. Schließlich ist die natürliche Merge-Auflösung zur Erstellung von N die Übernahme des Inhalts von file.txt in R, sodass N TREESAME zu R ist, aber nicht zu C. Die Merge-Commits O und P sind TREESAME zu ihren ersten Eltern, aber nicht zu ihren zweiten Eltern, Z bzw. Y.

Bei Verwendung des Standardmodus haben sowohl N als auch R einen TREESAME-Elternteil, daher werden diese Kanten durchlaufen und die anderen ignoriert. Der resultierende Historien-Graph ist

	I---X

Bei Verwendung von --full-history durchläuft Git jede Kante. Dies wird die Commits A und B sowie den Merge M aufdecken, wird aber auch die Merge-Commits O und P enthüllen. Mit Elternteil-Rewriting ist der resultierende Graph

	  .-A---M--------N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`--'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `------'

Hier tragen die Merge-Commits O und P zusätzlichen Lärm, da sie tatsächlich keine Änderung an file.txt vorgenommen haben. Sie haben nur ein Thema gemerged, das auf einer älteren Version von file.txt basierte. Dies ist ein häufiges Problem in Repositories, die einen Workflow verwenden, bei dem viele Mitwirkende parallel arbeiten und ihre Topic-Branches entlang eines einzelnen Stammes zusammenführen: Viele nicht zusammenhängende Merges erscheinen in den Ergebnissen von --full-history.

Bei Verwendung der Option --simplify-merges verschwinden die Commits O und P aus den Ergebnissen. Dies liegt daran, dass die neu geschriebenen zweiten Elternteile von O und P von ihren ersten Elternteilen erreichbar sind. Diese Kanten werden entfernt und dann sehen die Commits wie Single-Parent-Commits aus, die TREESAME zu ihrem Elternteil sind. Dies geschieht auch mit dem Commit N, was zu einer Historienansicht wie folgt führt:

	  .-A---M--.
	 /     /    \
	I     B      R
	 \   /      /
	  \ /      /
	   `---X--'

In dieser Ansicht sehen wir alle wichtigen Single-Parent-Änderungen von A, B und X. Wir sehen auch den sorgfältig aufgelösten Merge M und den nicht so sorgfältig aufgelösten Merge R. Dies ist normalerweise ausreichend, um zu bestimmen, warum die Commits A und B in der Standardansicht aus der Historie "verschwunden" sind. Es gibt jedoch einige Probleme mit diesem Ansatz.

Das erste Problem ist die Leistung. Im Gegensatz zu jeder früheren Option erfordert die Option --simplify-merges das Durchlaufen der gesamten Commit-Historie, bevor ein einzelnes Ergebnis zurückgegeben wird. Dies kann die Option für sehr große Repositories schwierig zu verwenden machen.

Das zweite Problem ist die Prüfung. Wenn viele Mitwirkende am selben Repository arbeiten, ist es wichtig, welche Merge-Commits eine Änderung in einen wichtigen Branch eingeführt haben. Der problematische Merge R oben ist wahrscheinlich nicht der Merge-Commit, der verwendet wurde, um in einen wichtigen Branch zu mergen. Stattdessen wurde der Merge N verwendet, um R und X in den wichtigen Branch zu mergen. Dieser Commit kann Informationen darüber enthalten, warum die Änderung X die Änderungen von A und B in seiner Commit-Nachricht überschrieben hat.

--show-pulls

Zusätzlich zu den im Standardverlauf angezeigten Commits werden alle Merge-Commits angezeigt, die nicht TREESAME zu ihrem ersten Elternteil sind, aber TREESAME zu einem späteren Elternteil sind.

Wenn ein Merge-Commit von --show-pulls einbezogen wird, wird der Merge so behandelt, als ob er die Änderung von einem anderen Branch "gezogen" hätte. Wenn --show-pulls auf dieses Beispiel angewendet wird (und keine anderen Optionen), ist der resultierende Graph

	I---X---R---N

Hier werden die Merge-Commits R und N einbezogen, da sie die Commits X bzw. R in den Basis-Branch "gezogen" haben. Diese Merges sind der Grund dafür, dass die Commits A und B nicht im Standardverlauf erscheinen.

Wenn --show-pulls mit --simplify-merges kombiniert wird, enthält der Graph alle notwendigen Informationen.

	  .-A---M--.   N
	 /     /    \ /
	I     B      R
	 \   /      /
	  \ /      /
	   `---X--'

Beachten Sie, dass, da M von R erreichbar ist, die Kante von N nach M vereinfacht wurde. N erscheint jedoch immer noch in der Historie als wichtiger Commit, da er die Änderung R in den Haupt-Branch "gezogen" hat.

Die Option --simplify-by-decoration ermöglicht es Ihnen, nur die Gesamtübersicht über die Topologie der Historie anzuzeigen, indem Commits weggelassen werden, die nicht von Tags referenziert werden. Commits werden als !TREESAME markiert (mit anderen Worten, nach den oben beschriebenen Historienvereinfachungsregeln beibehalten), wenn (1) sie von Tags referenziert werden oder (2) sie den Inhalt der auf der Befehlszeile angegebenen Pfade ändern. Alle anderen Commits werden als TREESAME markiert (können also vereinfacht wegfallen).

Commit-Reihenfolge

Standardmäßig werden die Commits in umgekehrt chronologischer Reihenfolge angezeigt.

--date-order

Zeigt keine Eltern an, bevor alle ihre Kinder angezeigt wurden, zeigt aber ansonsten Commits in der Reihenfolge der Commit-Zeitstempel an.

--author-date-order

Zeigt keine Eltern an, bevor alle ihre Kinder angezeigt wurden, zeigt aber ansonsten Commits in der Reihenfolge der Autoren-Zeitstempel an.

--topo-order

Zeigt keine Eltern an, bevor alle ihre Kinder angezeigt wurden, und vermeidet die Anzeige von Commits aus mehreren parallelen Verzweigungen vermischt.

Zum Beispiel in einer Commit-Historie wie dieser

    ---1----2----4----7
	\	       \
	 3----5----6----8---

wobei die Zahlen die Reihenfolge der Commit-Zeitstempel bezeichnen, zeigt git rev-list und ähnliche Befehle mit --date-order 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 ältere Commits werden vor neueren angezeigt, um die Anzeige von Commits aus zwei parallelen Entwicklungssträngen gemischt zu vermeiden.

--reverse

Gibt die ausgewählten Commits (siehe Abschnitt Commit-Begrenzung oben) in umgekehrter Reihenfolge aus. Kann nicht mit --walk-reflogs kombiniert werden.

Objekt-Traversierung

Diese Optionen sind hauptsächlich für das Packen von Git-Repositories gedacht.

--no-walk[=(sorted|unsorted)]: Zeigt nur die angegebenen Commits an, durchläuft aber nicht ihre Vorgänger. Dies hat keine Auswirkung, wenn ein Bereich angegeben ist. Wenn das Argument unsorted angegeben wird, werden die Commits in der Reihenfolge angezeigt, in der sie auf der Kommandozeile eingegeben wurden. Andernfalls (wenn sorted oder kein Argument angegeben wurde) werden die Commits in umgekehrt chronologischer Reihenfolge nach dem Commit-Zeitpunkt angezeigt. Kann nicht mit --graph kombiniert werden.
--do-walk: Überschreibt ein vorheriges --no-walk.

Commit-Formatierung

--pretty[=<format>]

--format=<format>

Gibt den Inhalt der Commit-Logs in einem bestimmten Format aus. <Format> kann eine der folgenden Optionen sein: oneline, short, medium, full, fuller, reference, email, raw, format:<Zeichenkette> und tformat:<Zeichenkette>. Wenn <Format> keine der oben genannten ist und ein %<Platzhalter> enthält, verhält es sich, als ob --pretty=tformat:<Format> angegeben worden wäre.

Siehe den Abschnitt "PRETTY FORMATS" für zusätzliche Details zu jedem Format. Wenn der Teil =<Format> weggelassen wird, wird standardmäßig medium verwendet.

Hinweis

Sie können das Standard-Schönheitsformat in der Repository-Konfiguration festlegen (siehe git-config[1]).

--abbrev-commit

Anstatt den vollständigen 40-stelligen hexadezimalen Commit-Objektnamen anzuzeigen, wird ein Präfix angezeigt, das das Objekt eindeutig benennt. Die Option --abbrev=<n> (die auch die Diff-Ausgabe beeinflusst, wenn sie angezeigt wird) kann verwendet werden, um die Mindestlänge des Präfixes festzulegen.

Dies sollte --pretty=oneline für Benutzer mit 80-stelligen Terminals wesentlich lesbarer machen.

--no-abbrev-commit

Zeigt den vollständigen 40-stelligen hexadezimalen Commit-Objektnamen an. Dies negiert --abbrev-commit, sei es explizit oder impliziert durch andere Optionen wie --oneline. Es überschreibt auch die Variable log.abbrevCommit.

--oneline

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

--encoding=<encoding>

Commit-Objekte speichern die Zeichenkodierung, die für die Log-Nachricht in ihrem Encoding-Header verwendet wurde. Diese Option kann verwendet werden, um den Befehl anzuweisen, die Commit-Log-Nachricht in die vom Benutzer bevorzugte Kodierung zu konvertieren. Für Nicht-Plumbing-Befehle ist dies standardmäßig UTF-8. Beachten Sie, dass, wenn ein Objekt als in X kodiert beansprucht wird und wir in X ausgeben, wir das Objekt unverändert ausgeben. Das bedeutet, dass ungültige Sequenzen im Original-Commit in die Ausgabe kopiert werden können. Ebenso, wenn iconv(3) die Konvertierung des Commits fehlschlägt, geben wir das Original-Objekt unverändert aus.

--expand-tabs=<n>

--expand-tabs

--no-expand-tabs

Führt eine Tabulatorerweiterung durch (ersetzt jeden Tabulator durch genügend Leerzeichen, um zur nächsten Spalte zu gelangen, die ein Vielfaches von <n> ist) in der Log-Nachricht, bevor sie in der Ausgabe angezeigt wird. --expand-tabs ist eine Kurzform für --expand-tabs=8 und --no-expand-tabs ist eine Kurzform für --expand-tabs=0, was die Tabulatorerweiterung deaktiviert.

Standardmäßig werden Tabs in Schönheitsformaten erweitert, die die Log-Nachricht um 4 Leerzeichen einrücken (d.h. medium, was die Standardeinstellung ist, full und fuller).

--notes[=<ref>]

Zeigt die Notizen (siehe git-notes[1]) an, die den Commit kommentieren, wenn die Commit-Log-Nachricht angezeigt wird. Dies ist die Standardeinstellung für die Befehle git log, git show und git whatchanged, wenn keine Option --pretty, --format oder --oneline auf der Befehlszeile angegeben ist.

Standardmäßig stammen die angezeigten Notizen aus den Notiz-Refs, die in den Variablen core.notesRef und notes.displayRef aufgeführt sind (oder entsprechende Umgebungsvariablen). Weitere Einzelheiten finden Sie in git-config[1].

Mit einem optionalen Argument <Ref> wird der Ref verwendet, um die anzuzeigenden Notizen zu finden. Der Ref kann den vollständigen Ref-Namen angeben, wenn er mit refs/notes/ beginnt; wenn er mit notes/ beginnt, werden refs/ und andernfalls refs/notes/ vorangestellt, um den vollständigen Namen des Refs zu bilden.

Mehrere Optionen --notes können kombiniert werden, um zu steuern, welche Notizen angezeigt werden. Beispiele: "--notes=foo" zeigt nur Notizen aus refs/notes/foo an; "--notes=foo --notes" zeigt sowohl Notizen aus "refs/notes/foo" als auch aus dem/den Standard-Notiz-Ref(s) an.

--no-notes

Zeigt keine Notizen an. Dies negiert die obige Option --notes, indem die Liste der Notiz-Refs zurückgesetzt wird, aus denen Notizen angezeigt werden. Optionen werden in der Reihenfolge ihrer Angabe auf der Befehlszeile geparst, sodass z. B. "--notes --notes=foo --no-notes --notes=bar" nur Notizen aus refs/notes/bar anzeigt.

--show-notes-by-default

Zeigt die Standardnotizen an, es sei denn, es werden Optionen zur Anzeige spezifischer Notizen angegeben.

--show-notes[=<ref>]

--standard-notes

--no-standard-notes

Diese Optionen sind veraltet. Verwenden Sie stattdessen die obigen Optionen --notes/--no-notes.

--show-signature

Überprüft die Gültigkeit eines signierten Commit-Objekts, indem die Signatur an gpg --verify übergeben und die Ausgabe angezeigt wird.

--relative-date

Synonym für --date=relative.

--date=<format>

Wirkt sich nur auf in menschenlesbarer Form angezeigte Daten aus, z. B. bei Verwendung von --pretty. Die Konfigurationsvariable log.date setzt einen Standardwert für die Option --date des Befehls log. Standardmäßig werden Daten in der ursprünglichen Zeitzone (entweder des Committer oder des Autors) angezeigt. Wenn -local an das Format angehängt wird (z. B. iso-local), wird stattdessen die lokale Zeitzone des Benutzers verwendet.

--date=relative zeigt Daten relativ zur aktuellen Zeit an, z. B. "vor 2 Stunden". Die Option -local hat keine Auswirkung für --date=relative.

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

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

ein Leerzeichen anstelle des Trennzeichens T für Datum/Uhrzeit
ein Leerzeichen zwischen Uhrzeit und Zeitzone
kein Doppelpunkt zwischen Stunden und Minuten der Zeitzone

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

--date=rfc (oder --date=rfc2822) zeigt Zeitstempel im RFC 2822-Format an, das oft in E-Mails zu finden ist.

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

--date=raw zeigt das Datum als Sekunden seit der Epoche (1970-01-01 00:00:00 UTC) gefolgt von einem Leerzeichen und dann der Zeitzone als Offset von UTC (ein + oder - mit vier Ziffern; die ersten beiden sind Stunden, die zweiten beiden Minuten). Also, als ob der Zeitstempel mit strftime("%s %z") formatiert worden wäre. Beachten Sie, dass die Option -local den Wert der Sekunden seit der Epoche (der immer in UTC gemessen wird) nicht beeinflusst, aber den begleitenden Zeitzonenwert umschaltet.

--date=human zeigt die Zeitzone an, wenn die Zeitzone nicht mit der aktuellen Zeitzone übereinstimmt, und gibt das gesamte Datum nicht aus, wenn es übereinstimmt (d.h. überspringt die Ausgabe des Jahres für Daten "dieses Jahr", überspringt aber auch das gesamte Datum selbst, wenn es in den letzten Tagen liegt und wir nur den Wochentag angeben können). Für ältere Daten werden auch die Stunde und die Minute weggelassen.

--date=unix zeigt das Datum als Unix-Epochen-Zeitstempel (Sekunden seit 1970) an. Wie bei --raw ist dies immer in UTC und daher hat -local keine Auswirkung.

--date=format:<format> übergibt das <format> an Ihre System- strftime Funktion, mit Ausnahme von %s, %z und %Z, die intern behandelt werden. Verwenden Sie --date=format:%c, um das Datum im bevorzugten Format Ihrer System-Locale anzuzeigen. Siehe die Manpage strftime(3) für eine vollständige Liste der Platzhalter. Bei Verwendung von -local lautet die korrekte Syntax --date=format-local:<format>.

--date=default ist das Standardformat und basiert auf der ctime(3)-Ausgabe. Es zeigt eine einzelne Zeile mit dreibuchstabigem Wochentag, dreibuchstabigem Monat, Tag des Monats, Stunden-Minuten-Sekunden im Format "HH:MM:SS", gefolgt von der vierstelligen Jahreszahl und Zeitzoneninformationen, es sei denn, die lokale Zeitzone wird verwendet, z. B. Do Jan 1 00:00:00 1970 +0000.

--parents

Gibt auch die Eltern des Commits aus (in der Form "commit parent…"). Aktiviert auch das Umschreiben von Eltern, siehe History Simplification oben.

--children

Gibt auch die Kinder des Commits aus (in der Form "commit child…"). Aktiviert auch das Umschreiben von Eltern, siehe History Simplification oben.

--left-right

Markiert, von welcher Seite einer symmetrischen Differenz ein Commit erreichbar ist. Commits von der linken Seite werden mit < und die von der rechten Seite mit > präfixiert. Wenn diese Option mit --boundary kombiniert wird, werden diese Commits mit - präfixiert.

Zum Beispiel, wenn Sie diese Topologie haben

	     y---b---b  branch B
	    / \ /
	   /   .
	  /   / \
	 o---x---a---a  branch A

erhalten Sie eine Ausgabe wie diese

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

	>bbbbbbb... 3rd on b
	>bbbbbbb... 2nd on b
	<aaaaaaa... 3rd on a
	<aaaaaaa... 2nd on a
	-yyyyyyy... 1st on b
	-xxxxxxx... 1st on a

--graph

Zeichnet eine textbasierte grafische Darstellung der Commit-Historie auf der linken Seite der Ausgabe. Dies kann dazu führen, dass zusätzliche Zeilen zwischen den Commits gedruckt werden, damit die Graphenhistorie korrekt gezeichnet werden kann. Kann nicht mit --no-walk kombiniert werden.

Dies aktiviert das Umschreiben von Eltern, siehe History Simplification oben.

Dies impliziert standardmäßig die Option --topo-order, aber die Option --date-order kann ebenfalls angegeben werden.

--show-linear-break[=<barriere>]

Wenn --graph nicht verwendet wird, werden alle Historienzweige abgeflacht, was es schwierig machen kann zu erkennen, dass die beiden aufeinanderfolgenden Commits nicht zu einem linearen Zweig gehören. Diese Option platziert in diesem Fall eine Barriere dazwischen. Wenn <barriere> angegeben ist, ist dies die Zeichenkette, die anstelle der Standardzeichenkette angezeigt wird.

SCHÖNE FORMATE

Wenn der Commit ein Merge ist und das Pretty-Format nicht oneline, email oder raw ist, wird vor der Zeile Author: eine zusätzliche Zeile eingefügt. Diese Zeile beginnt mit "Merge: " und die Hashes der Vorfahren-Commits werden durch Leerzeichen getrennt ausgegeben. Beachten Sie, dass die aufgeführten Commits nicht unbedingt die Liste der direkten Eltern-Commits sind, wenn Sie Ihre Ansicht der Historie eingeschränkt haben: z. B. wenn Sie nur an Änderungen im Zusammenhang mit einem bestimmten Verzeichnis oder einer Datei interessiert sind.

Es gibt mehrere eingebaute Formate, und Sie können zusätzliche Formate definieren, indem Sie eine `pretty.`-Konfigurationsoption entweder auf einen anderen Formatnamen oder eine format:-Zeichenkette setzen, wie unten beschrieben (siehe git-config[1]). Hier sind die Details der integrierten Formate:

oneline
```
<hash> <title-line>
```
Dies ist so konzipiert, dass es so kompakt wie möglich ist.

short

commit <hash>
Author: <author>

<title-line>

medium

commit <hash>
Author: <author>
Date:   <author-date>

<title-line>

<full-commit-message>

full

commit <hash>
Author: <author>
Commit: <committer>

<title-line>

<full-commit-message>

fuller

commit <hash>
Author:     <author>
AuthorDate: <author-date>
Commit:     <committer>
CommitDate: <committer-date>

<title-line>

<full-commit-message>

reference
```
<abbrev-hash> (<title-line>, <short-author-date>)
```
Dieses Format wird verwendet, um in einer Commit-Nachricht auf einen anderen Commit zu verweisen und ist dasselbe wie --pretty='format:%C(auto)%h (%s, %ad). Standardmäßig wird das Datum mit --date=short formatiert, es sei denn, eine andere Option --date wird explizit angegeben. Wie bei jedem format: mit Formatplatzhaltern wird seine Ausgabe nicht von anderen Optionen wie --decorate und --walk-reflogs beeinflusst.

email

From <hash> <date>
From: <author>
Date: <author-date>
Subject: [PATCH] <title-line>

<full-commit-message>

mboxrd

Wie email, aber Zeilen in der Commit-Nachricht, die mit "From " beginnen (vorangestellt von null oder mehr ">"), werden mit ">" zitiert, damit sie nicht mit dem Beginn eines neuen Commits verwechselt werden.
raw

Das raw-Format zeigt den gesamten Commit genau so an, wie er im Commit-Objekt gespeichert ist. Insbesondere werden die Hashes vollständig angezeigt, unabhängig davon, ob --abbrev oder --no-abbrev verwendet werden, und die Eltern-Informationen zeigen die tatsächlichen Eltern-Commits an, ohne Grafts oder Historienvereinfachung zu berücksichtigen. Beachten Sie, dass dieses Format die Art und Weise beeinflusst, wie Commits angezeigt werden, aber nicht, wie der Diff angezeigt wird, z. B. mit git log --raw. Um vollständige Objektnamen in einem rohen Diff-Format zu erhalten, verwenden Sie --no-abbrev.
format:<Format-Zeichenkette>

Das Format format:<Format-Zeichenkette> ermöglicht es Ihnen, anzugeben, welche Informationen Sie anzeigen möchten. Es funktioniert ähnlich wie das printf-Format, mit der bemerkenswerten Ausnahme, dass Sie anstelle von \n einen Zeilenumbruch mit %n erhalten.

Zum Beispiel würde format:"Der Autor von %h war %an, %ar%nDer Titel war >>%s<<%n" etwa Folgendes anzeigen:
```
The author of fe6e0ee was Junio C Hamano, 23 hours ago
The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
```
Die Platzhalter sind
- Platzhalter, die sich zu einem einzelnen literalen Zeichen erweitern
  
  %n
  
  Zeilenumbruch
  
  %%
  
  ein rohes %
  
  %x00
  
  % gefolgt von zwei Hexadezimalziffern wird durch ein Byte mit dem Wert der Hexadezimalziffern ersetzt (wir nennen dies im Folgenden "Literal-Formatcode").
- Platzhalter, die die Formatierung späterer Platzhalter beeinflussen
  
  %Cred
  
  Farbe auf Rot umstellen
  
  %Cgreen
  
  Farbe auf Grün umstellen
  
  %Cblue
  
  Farbe auf Blau umstellen
  
  %Creset
  
  Farbe zurücksetzen
  
  %C(<spec>)
  
  Farbspezifikation, wie unter Values im Abschnitt "CONFIGURATION FILE" von git-config[1] beschrieben. Standardmäßig werden Farben nur angezeigt, wenn sie für die Log-Ausgabe aktiviert sind (durch color.diff, color.ui oder --color und unter Berücksichtigung der auto-Einstellungen des ersteren, wenn wir zu einem Terminal schreiben). %C(auto,<spec>) wird als historische Synonym für den Standard akzeptiert (z. B. %C(auto,red)). Die Angabe von %C(always,<spec>) zeigt die Farben auch dann an, wenn die Farbe nicht anderweitig aktiviert ist (erwägen Sie jedoch die Verwendung von --color=always, um die Farbe für die gesamte Ausgabe zu aktivieren, einschließlich dieses Formats und allem anderen, was Git farblich hervorheben könnte). auto allein (d.h. %C(auto)) schaltet die automatische Farbwahl für die nachfolgenden Platzhalter ein, bis die Farbe wieder geändert wird.
  
  %m
  
  linke (<), rechte (>) oder Begrenzungsmarkierung (-)
  
  %w([<w>[,<i1>[,<i2>]]])
  
  Zeilenumbruch umschalten, wie die Option -w von git-shortlog[1].
  
  %<(<n>[,(trunc|ltrunc|mtrunc)])
  
  Der nächste Platzhalter nimmt mindestens N Spaltenbreiten ein, wobei bei Bedarf Leerzeichen rechts aufgefüllt werden. Optional wird links (ltrunc) ..ft, in der Mitte (mtrunc) mi..le oder am Ende (trunc) rig.. abgeschnitten (mit Ellipsen ..), wenn die Ausgabe länger als <n> Spalten ist. Hinweis 1: Das Abschneiden funktioniert nur korrekt mit <n> >= 2. Hinweis 2: Leerzeichen um die Werte <n> und <m> (siehe unten) sind optional. Hinweis 3: Emojis und andere breite Zeichen nehmen zwei Anzeigespalten ein, was Spaltengrenzen überschreiten kann. Hinweis 4: kombinierte Zeichen von Zeichen mit diakritischen Zeichen können an Auffüllgrenzen falsch platziert werden.
  
  %<|(<m> )
  
  Der nächste Platzhalter nimmt mindestens bis zur <m>-ten Anzeigespalte ein, wobei bei Bedarf Leerzeichen rechts aufgefüllt werden. Verwenden Sie negative <m>-Werte für Spaltenpositionen, die vom rechten Rand des Terminalfensters gemessen werden.
  
  %>(<n>)
  
  %>|(<m>)
  
  ähnlich wie %<(<n>), %<|(<m>), aber mit Auffüllen von Leerzeichen auf der linken Seite
  
  %>>(<n>)
  
  %>>|(<m>)
  
  ähnlich wie %>(<n>), %>|(<m>), außer dass bei Bedarf Leerzeichen auf der linken Seite verwendet werden, wenn der nächste Platzhalter mehr Platz benötigt als angegeben
  
  %><(<n>)
  
  %><|(<m>)
  
  ähnlich wie %<(<n>), %<|(<m>), aber mit Auffüllen auf beiden Seiten (d.h. der Text ist zentriert)
- Platzhalter, die sich zu Informationen aus dem Commit erweitern
  %H
  
  Commit-Hash
  
  %h
  
  abgekürzter Commit-Hash
  
  %T
  
  Tree-Hash
  
  %t
  
  abgekürzter Tree-Hash
  
  %P
  
  Eltern-Hashes
  
  %p
  
  abgekürzte Eltern-Hashes
  
  %an
  
  Autor-Name
  
  %aN
  
  Autor-Name (beachtet .mailmap, siehe git-shortlog[1] oder git-blame[1])
  
  %ae
  
  Autor-E-Mail
  
  %aE
  
  Autor-E-Mail (beachtet .mailmap, siehe git-shortlog[1] oder git-blame[1])
  
  %al
  
  Autor-E-Mail lokal-Teil (der Teil vor dem Zeichen @)
  
  %aL
  
  Autor-Lokalteil (siehe %al), beachtet .mailmap, siehe git-shortlog[1] oder git-blame[1])
  
  %ad
  
  Autor-Datum (Format beachtet die Option --date=)
  
  %aD
  
  Autor-Datum, RFC2822-Stil
  
  %ar
  
  Autor-Datum, relativ
  
  %at
  
  Autor-Datum, UNIX-Zeitstempel
  
  %ai
  
  Autor-Datum, ISO 8601-ähnliches Format
  
  %aI
  
  Autor-Datum, striktes ISO 8601-Format
  
  %as
  
  Autor-Datum, kurzes Format (JJJJ-MM-TT)
  
  %ah
  
  Autor-Datum, menschenlesbarer Stil (wie die Option --date=human von git-rev-list[1])
  
  %cn
  
  Committer-Name
  
  %cN
  
  Committer-Name (beachtet .mailmap, siehe git-shortlog[1] oder git-blame[1])
  
  %ce
  
  Committer-E-Mail
  
  %cE
  
  Committer-E-Mail (beachtet .mailmap, siehe git-shortlog[1] oder git-blame[1])
  
  %cl
  
  Committer-E-Mail lokal-Teil (der Teil vor dem Zeichen @)
  
  %cL
  
  Committer-Lokalteil (siehe %cl), beachtet .mailmap, siehe git-shortlog[1] oder git-blame[1])
  
  %cd
  
  Committer-Datum (Format beachtet 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
  
  %cs
  
  Committer-Datum, kurzes Format (JJJJ-MM-TT)
  
  %ch
  
  Committer-Datum, menschenlesbarer Stil (wie die Option --date=human von git-rev-list[1])
  
  %d
  
  Ref-Namen, wie die Option --decorate von git-log[1]
  
  %D
  
  Ref-Namen ohne die Klammern "(", ")".
  
  %(decorate[:<option>,...])
  
  Ref-Namen mit benutzerdefinierten Dekorationen. Die Zeichenkette decorate kann gefolgt von einem Doppelpunkt und null oder mehr durch Kommas getrennten Optionen sein. Optionswerte können literale Formatierungscodes enthalten. Diese müssen für Kommas (%x2C) und schließende Klammern (%x29) verwendet werden, aufgrund ihrer Rolle in der Optionssyntax.
  
  prefix=<Wert>: Wird vor der Liste der Ref-Namen angezeigt. Standardmäßig " (".
  
  suffix=<Wert>: Wird nach der Liste der Ref-Namen angezeigt. Standardmäßig ")".
  
  separator=<Wert>: Wird zwischen den Ref-Namen angezeigt. Standardmäßig ", ".
  
  pointer=<Wert>: Wird zwischen HEAD und dem Branch, auf den es zeigt (falls vorhanden), angezeigt. Standardmäßig " → ".
  
  tag=<Wert>: Wird vor den Tag-Namen angezeigt. Standardmäßig "tag: ".
Zum Beispiel, um Dekorationen ohne Umbruch oder Tag-Annotationen und mit Leerzeichen als Trennzeichen zu erzeugen:

%(decorate:prefix=,suffix=,tag=,separator= )
%(describe[:<option>,...])
Menschenlesbarer Name, wie git-describe[1]; leere Zeichenkette für nicht beschreibbare Commits. Die Zeichenkette describe kann gefolgt von einem Doppelpunkt und null oder mehr durch Kommas getrennten Optionen sein. Beschreibungen können inkonsistent sein, wenn Tags gleichzeitig hinzugefügt oder entfernt werden.
tags[=<Bool-Wert>]: Anstatt nur annotierte Tags zu berücksichtigen, werden auch Lightweight-Tags berücksichtigt.

abbrev=<Nummer>: Anstatt die Standardanzahl von Hexadezimalziffern (die je nach Anzahl der Objekte im Repository variiert, standardmäßig 7) des abgekürzten Objektnamens zu verwenden, werden <Nummer> Ziffern verwendet, oder so viele Ziffern wie nötig, um einen eindeutigen Objektnamen zu bilden.

match=<Muster>: Berücksichtigt nur Tags, die dem angegebenen glob(7)-Muster entsprechen, wobei der Präfix refs/tags/ ausgeschlossen ist.

exclude=<Muster>: Berücksichtigt keine Tags, die dem angegebenen glob(7)-Muster entsprechen, wobei der Präfix refs/tags/ ausgeschlossen ist.
%S

Ref-Name, der auf der Befehlszeile angegeben wurde und mit dem der Commit erreicht wurde (wie bei git log --source), funktioniert nur mit git log

%e

Encoding

%s

Betreffzeile

%f

bereinigte Betreffzeile, geeignet für einen Dateinamen

%b

Nachrichtentext

%B

roher Nachrichtentext (ungebrochene Betreffzeile und Nachrichtentext)

%N

Commit-Notizen

%GG

rohe Verifizierungsnachricht von GPG für einen signierten Commit

%G?

zeigt "G" für eine gültige Signatur, "B" für eine ungültige Signatur, "U" für eine gültige Signatur mit unbekannter Gültigkeit, "X" für eine gültige Signatur, die abgelaufen ist, "Y" für eine gültige Signatur, die von einem abgelaufenen Schlüssel erstellt wurde, "R" für eine gültige Signatur, die von einem widerrufenen Schlüssel erstellt wurde, "E", wenn die Signatur nicht überprüft werden kann (z.B. fehlender Schlüssel) und "N" für keine Signatur.

%GS

zeigt den Namen des Unterzeichners für einen signierten Commit an

%GK

zeigt den verwendeten Schlüssel zum Signieren eines signierten Commits an

%GF

zeigt den Fingerabdruck des Schlüssels an, der zum Signieren eines signierten Commits verwendet wurde

%GP

zeigt den Fingerabdruck des primären Schlüssels an, dessen Unterschlüssel zum Signieren eines signierten Commits verwendet wurde

%GT

zeigt die Vertrauensstufe für den zum Signieren eines signierten Commits verwendeten Schlüssel an

%gD

Reflog-Selektor, z.B. refs/stash@{1} oder refs/stash@{2 Minuten vor}; das Format folgt den Regeln, die für die Option -g beschrieben sind. Der Teil vor dem @ ist der Refname, wie er auf der Befehlszeile angegeben wurde (also git log -g refs/heads/master würde refs/heads/master@{0} ergeben).

%gd

abgekürzter Reflog-Selektor; wie %gD, aber der Refname-Teil ist zur besseren Lesbarkeit abgekürzt (also refs/heads/master wird zu nur master).

%gn

Reflog-Identitätsname

%gN

Reflog-Identitätsname (beachtet .mailmap, siehe git-shortlog[1] oder git-blame[1])

%ge

Reflog-Identitäts-E-Mail

%gE

Reflog-Identitäts-E-Mail (beachtet .mailmap, siehe git-shortlog[1] oder git-blame[1])

%gs

Reflog-Betreff

%(trailers[:<option>,...])
zeigt die Trailer des Nachrichtentexts an, wie sie von git-interpret-trailers[1] interpretiert werden. Die Zeichenkette trailers kann gefolgt von einem Doppelpunkt und null oder mehr durch Kommas getrennten Optionen sein. Wenn eine Option mehrmals angegeben wird, gewinnt die letzte Angabe.
key=<Schlüssel>: zeigt nur Trailer mit dem angegebenen <Schlüssel> an. Die Übereinstimmung erfolgt ohne Berücksichtigung der Groß-/Kleinschreibung, und der abschließende Doppelpunkt ist optional. Wenn die Option mehrmals angegeben wird, werden Trailer-Zeilen angezeigt, die mit einem der Schlüssel übereinstimmen. Diese Option aktiviert automatisch die Option only, sodass Nicht-Trailer-Zeilen im Trailer-Block ausgeblendet werden. Wenn dies nicht gewünscht ist, kann es mit only=false deaktiviert werden. Beispiel: %(trailers:key=Reviewed-by) zeigt Trailer-Zeilen mit dem Schlüssel Reviewed-by an.

only[=<Bool>]: wählt aus, ob Nicht-Trailer-Zeilen aus dem Trailer-Block einbezogen werden sollen.

separator=<sep>: gibt den Trenner an, der zwischen den Trailer-Zeilen eingefügt wird. Standardmäßig ein Zeilenumbruchzeichen. Die Zeichenkette <sep> kann die oben beschriebenen literalen Formatierungscodes enthalten. Um ein Komma als Trenner zu verwenden, muss %x2C verwendet werden, da es andernfalls als nächste Option interpretiert würde. Beispiel: %(trailers:key=Ticket,separator=%x2C ) zeigt alle Trailer-Zeilen mit dem Schlüssel "Ticket" an, getrennt durch ein Komma und ein Leerzeichen.

unfold[=<Bool>]: bewirkt, dass es sich so verhält, als ob die Option --unfold von interpret-trailer gegeben worden wäre. Beispiel: %(trailers:only,unfold=true) entfaltet und zeigt alle Trailer-Zeilen an.

keyonly[=<Bool>]: zeigt nur den Schlüsselteil des Trailers an.

valueonly[=<bool>]: Zeigt nur den Wert des Trailers an.

key_value_separator=<sep>: Legt den Trenner fest, der zwischen Schlüssel und Wert jedes Trailers eingefügt wird. Standard ist ": ". Andernfalls gelten dieselben Semantik wie bei separator=<sep> oben.

Hinweis

Einige Platzhalter können von anderen Optionen des Revisionsverlauf-Engines abhängen. Beispielsweise fügen die %g* Reflog-Optionen einen leeren String ein, es sei denn, wir durchlaufen Reflog-Einträge (z. B. mit git log -g). Die Platzhalter %d und %D verwenden das "kurze" Dekorationsformat, wenn --decorate nicht bereits auf der Befehlszeile angegeben wurde.

Die booleschen Optionen akzeptieren einen optionalen Wert [=<bool-value>]. Die Werte von --type=bool in git-config[1], wie yes und off, werden alle akzeptiert. Eine boolesche Option ohne =<value> zu geben, ist gleichbedeutend damit, sie mit =true zu geben.

Wenn Sie ein + (Pluszeichen) nach dem % eines Platzhalters hinzufügen, wird unmittelbar vor der Expansion ein Zeilenumbruch eingefügt, wenn und nur wenn der Platzhalter zu einem nicht-leeren String expandiert.

Wenn Sie ein - (Minuszeichen) nach dem % eines Platzhalters hinzufügen, werden alle aufeinanderfolgenden Zeilenumbrüche unmittelbar vor der Expansion gelöscht, wenn und nur wenn der Platzhalter zu einem leeren String expandiert.

Wenn Sie ein Leerzeichen ( ) nach dem % eines Platzhalters hinzufügen, wird unmittelbar vor der Expansion ein Leerzeichen eingefügt, wenn und nur wenn der Platzhalter zu einem nicht-leeren String expandiert.

tformat

Das tformat: Format funktioniert genau wie format:, bietet aber "Terminator"-Semantik anstelle von "Separator"-Semantik. Mit anderen Worten, jeder Commit erhält das Nachrichtenabschlussterminalzeichen (normalerweise ein Zeilenumbruch) angehängt, anstatt eines Separators zwischen den Einträgen. Das bedeutet, dass der letzte Eintrag eines einzeiligen Formats ordnungsgemäß mit einem Zeilenumbruch terminiert wird, genau wie das "oneline"-Format. Zum Beispiel
```
$ git log -2 --pretty=format:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973 -- NO NEWLINE

$ git log -2 --pretty=tformat:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973
```
Darüber hinaus wird jeder nicht erkannte String, der ein % enthält, so interpretiert, als ob tformat: davor stünde. Diese beiden sind zum Beispiel äquivalent
```
$ git log -2 --pretty=tformat:%h 4da45bef
$ git log -2 --pretty=%h 4da45bef
```

DIFF-FORMATIERUNG

Standardmäßig generiert git log keine Diff-Ausgabe. Die unten aufgeführten Optionen können verwendet werden, um die von jedem Commit vorgenommenen Änderungen anzuzeigen.

Beachten Sie, dass Merge-Commits keine Diff-Ausgabe erzeugen, es sei denn, einer der Varianten von --diff-merges (einschließlich der Kurzformen -m, -c, --cc und --dd) wird explizit angegeben, auch wenn ein Diff-Format wie --patch ausgewählt ist, und sie entsprechen auch keinen Suchoptionen wie -S. Die Ausnahme ist, wenn --first-parent verwendet wird, in diesem Fall ist first-parent das Standardformat für Merge-Commits.

-p

-u

--patch

Generiert einen Patch (siehe Patch-Text mit -p generieren).

-s

--no-patch

Unterdrückt jegliche Ausgabe der Diff-Maschinerie. Nützlich für Befehle wie git show, die standardmäßig den Patch anzeigen, um ihre Ausgabe zu unterdrücken, oder um die Wirkung von Optionen wie --patch, --stat, die früher auf der Befehlszeile in einem Alias standen, aufzuheben.

-m

Zeigt Diffs für Merge-Commits im Standardformat an. Dies ähnelt --diff-merges=on, außer dass -m keine Ausgabe erzeugt, es sei denn, -p wird ebenfalls angegeben.

-c

Erzeugt eine kombinierte Diff-Ausgabe für Merge-Commits. Kurzerhand für --diff-merges=combined -p.

--cc

Erzeugt eine dichte kombinierte Diff-Ausgabe für Merge-Commits. Kurzerhand für --diff-merges=dense-combined -p.

--dd

Erzeugt einen Diff bezüglich des ersten Parents für sowohl Merge- als auch reguläre Commits. Kurzerhand für --diff-merges=first-parent -p.

--remerge-diff

Erzeugt eine Remerge-Diff-Ausgabe für Merge-Commits. Kurzerhand für --diff-merges=remerge -p.

--no-diff-merges

Synonym für --diff-merges=off.

--diff-merges=<format>

Gibt das für Merge-Commits zu verwendende Diff-Format an. Standard ist `off`, es sei denn, --first-parent wird verwendet, in diesem Fall ist first-parent der Standard.

Die folgenden Formate werden unterstützt

off
none: Deaktiviert die Ausgabe von Diffs für Merge-Commits. Nützlich, um implizite Werte zu überschreiben.
on
m: Bewirkt, dass die Diff-Ausgabe für Merge-Commits im Standardformat angezeigt wird. Das Standardformat kann mit der Konfigurationsvariable log.diffMerges geändert werden, deren Standardwert separate ist.
first-parent
1: Zeigt den vollständigen Diff in Bezug auf den ersten Parent an. Dies ist das gleiche Format, das --patch für Nicht-Merge-Commits erzeugt.
separate: Zeigt den vollständigen Diff in Bezug auf jeden der Parents an. Für jeden Parent wird ein separater Log-Eintrag und Diff generiert.
combined
c: Zeigt gleichzeitig die Unterschiede von jedem der Parents zum Merge-Ergebnis an, anstatt paarweise einen Diff zwischen einem Parent und dem Ergebnis nacheinander anzuzeigen. Außerdem werden nur Dateien aufgelistet, die sich von allen Parents unterschieden haben.
dense-combined
cc: Verdichtet die von --diff-merges=combined erzeugte Ausgabe weiter, indem uninteressante Hunks ausgelassen werden, deren Inhalte in den Parents nur zwei Varianten aufweisen und das Merge-Ergebnis ohne Änderung eine davon wählt.
remerge
r: Führt für Zwei-Parent-Merge-Commits eine erneute Zusammenführung durch, um ein temporäres Baumobjekt zu erstellen – potenziell mit Dateien mit Konfliktmarkierungen usw. Anschließend wird ein Diff zwischen diesem temporären Baum und dem tatsächlichen Merge-Commit angezeigt.

Die mit dieser Option erzeugte Ausgabe kann sich ändern, ebenso wie ihre Interaktion mit anderen Optionen (sofern nicht ausdrücklich dokumentiert).

--combined-all-paths

Bewirkt, dass kombinierte Diffs (für Merge-Commits verwendet) den Dateinamen von allen Parents auflisten. Dies hat also nur dann Auswirkungen, wenn --diff-merges=[dense-]combined verwendet wird, und ist wahrscheinlich nur nützlich, wenn Dateinamensänderungen erkannt wurden (d.h. wenn Umbenennungs- oder Kopiererkennung angefordert wurde).

-U<n>

--unified=<n>

Generiert Diffs mit <n> Zeilen Kontext anstelle der üblichen drei. Beinhaltet --patch.

--output=<file>

Ausgabe in eine bestimmte Datei anstelle von stdout.

--output-indicator-new=<char>

--output-indicator-old=<char>

--output-indicator-context=<char>

Legt das Zeichen fest, das verwendet wird, um neue, alte oder Kontextzeilen im generierten Patch anzuzeigen. Normalerweise sind dies +, - und ' '.

--raw

Zeigt für jeden Commit eine Zusammenfassung der Änderungen im Rohdiff-Format an. Siehe den Abschnitt "RAW OUTPUT FORMAT" in git-diff[1]. Dies unterscheidet sich vom Anzeigen des Logs selbst im Rohformat, was Sie mit --format=raw erreichen können.

--patch-with-raw

Synonym für -p --raw.

-t

Zeigt die Baumobjekte in der Diff-Ausgabe an.

--indent-heuristic

Aktiviert die Heuristik, die Diff-Hunk-Grenzen verschiebt, um Patches leichter lesbar zu machen. Dies ist der Standard.

--no-indent-heuristic

Deaktiviert die Einrückungsheuristik.

--minimal

Verwendet zusätzliche Zeit, um sicherzustellen, dass der kleinstmögliche Diff erzeugt wird.

--patience

Generiert einen Diff mit dem "Patience Diff"-Algorithmus.

--histogram

Generiert einen Diff mit dem "Histogramm Diff"-Algorithmus.

--anchored=<text>

Generiert einen Diff mit dem "Anchored Diff"-Algorithmus.

Diese Option kann mehrfach angegeben werden.

Wenn eine Zeile sowohl in der Quelle als auch im Ziel existiert, nur einmal vorkommt und mit <text> beginnt, versucht dieser Algorithmus zu verhindern, dass sie als Löschung oder Hinzufügung in der Ausgabe erscheint. Er verwendet intern den "Patience Diff"-Algorithmus.

--diff-algorithm=(patience|minimal|histogram|myers)

Wählt einen Diff-Algorithmus aus. Die Varianten sind wie folgt:

default
myers: Der grundlegende Greedy-Diff-Algorithmus. Derzeit ist dies der Standard.
minimal: Verwendet zusätzliche Zeit, um sicherzustellen, dass der kleinstmögliche Diff erzeugt wird.
patience: Verwendet den "Patience Diff"-Algorithmus bei der Generierung von Patches.
histogram: Dieser Algorithmus erweitert den Patience-Algorithmus, um "gemeinsame Elemente mit geringer Häufigkeit" zu unterstützen.

Wenn Sie beispielsweise die Variable diff.algorithm auf einen anderen Wert als den Standardwert konfiguriert haben und den Standardwert verwenden möchten, müssen Sie die Option --diff-algorithm=default verwenden.

--stat[=<width>[,<name-width>[,<count>]]]

Generiert eine Diff-Statistik. Standardmäßig wird so viel Platz wie nötig für den Dateinamens-Teil verwendet, und der Rest für den Graphen-Teil. Die maximale Breite beträgt standardmäßig die Terminalbreite oder 80 Spalten, wenn keine Verbindung zu einem Terminal besteht, und kann durch <width> überschrieben werden. Die Breite des Dateinamens-Teils kann durch Angabe einer weiteren Breite <name-width> nach einem Komma oder durch Setzen von diff.statNameWidth=<name-width> begrenzt werden. Die Breite des Graphen-Teils kann durch Verwendung von --stat-graph-width=<graph-width> oder durch Setzen von diff.statGraphWidth=<graph-width> begrenzt werden. Die Verwendung von --stat oder --stat-graph-width beeinflusst alle Befehle, die einen Stat-Graphen generieren, während das Setzen von diff.statNameWidth oder diff.statGraphWidth git format-patch nicht beeinflusst. Durch Angabe eines dritten Parameters <count> können Sie die Ausgabe auf die ersten <count> Zeilen begrenzen, gefolgt von ..., wenn mehr vorhanden sind.

Diese Parameter können auch einzeln mit --stat-width=<width>, --stat-name-width=<name-width> und --stat-count=<count> eingestellt werden.

--compact-summary

Gibt eine komprimierte Zusammenfassung von erweiterten Kopfzeileninformationen aus, wie z. B. Dateierstellungen oder -löschungen ("new" oder "gone", optional +l bei Symlinks) und Modusänderungen (+x oder -x zum Hinzufügen oder Entfernen des ausführbaren Bits) im Diffstat. Die Informationen werden zwischen dem Dateinamen-Teil und dem Grafik-Teil platziert. Beinhaltet --stat.

--numstat

Ähnlich wie --stat, zeigt aber die Anzahl der hinzugefügten und gelöschten Zeilen in Dezimaldarstellung und den Pfadnamen ohne Abkürzung an, um ihn maschinenfreundlicher zu machen. Für Binärdateien werden zwei - ausgegeben, anstatt 0 0 anzuzeigen.

--shortstat

Gibt nur die letzte Zeile des --stat Formats aus, die die Gesamtzahl der geänderten Dateien sowie die Anzahl der hinzugefügten und gelöschten Zeilen enthält.

-X [<param>,...]

--dirstat[=<param>,...]

Gibt die Verteilung des relativen Änderungsanteils für jedes Unterverzeichnis aus. Das Verhalten von --dirstat kann durch Übergabe einer kommagetrennten Liste von Parametern angepasst werden. Die Standardwerte werden durch die Konfigurationsvariable diff.dirstat gesteuert (siehe git-config[1]). Folgende Parameter sind verfügbar:

changes: Berechnet die Dirstat-Zahlen durch Zählen der aus der Quelle entfernten oder in das Ziel hinzugefügten Zeilen. Dies ignoriert den Umfang reiner Codebewegungen innerhalb einer Datei. Mit anderen Worten, das Neuordnen von Zeilen in einer Datei wird nicht so stark gezählt wie andere Änderungen. Dies ist das Standardverhalten, wenn kein Parameter angegeben wird.
lines: Berechnet die Dirstat-Zahlen, indem die reguläre zeilenbasierte Diff-Analyse durchgeführt und die Anzahl der entfernten/hinzugefügten Zeilen summiert wird. (Für Binärdateien werden stattdessen 64-Byte-Chunks gezählt, da Binärdateien kein natürliches Konzept von Zeilen haben.) Dies ist ein teureres --dirstat-Verhalten als das changes-Verhalten, zählt aber auch neu angeordnete Zeilen innerhalb einer Datei ebenso wie andere Änderungen. Die resultierende Ausgabe stimmt mit dem überein, was Sie von den anderen --*stat-Optionen erhalten.
files: Berechnet die Dirstat-Zahlen durch Zählen der Anzahl der geänderten Dateien. Jede geänderte Datei zählt gleichmäßig in der Dirstat-Analyse. Dies ist das rechnerisch günstigste --dirstat-Verhalten, da es den Dateiinhalt überhaupt nicht berücksichtigen muss.
cumulative: Zählt die Änderungen in einem Unterverzeichnis auch für das übergeordnete Verzeichnis. Beachten Sie, dass bei Verwendung von cumulative die Summe der angezeigten Prozentsätze 100 % überschreiten kann. Das Standardverhalten (nicht kumulativ) kann mit dem Parameter noncumulative angegeben werden.
<limit>: Ein Integer-Parameter gibt einen Schwellenwertprozentsatz an (standardmäßig 3 %). Verzeichnisse, die weniger als dieser Prozentsatz der Änderungen beitragen, werden nicht in der Ausgabe angezeigt.

Beispiel: Folgendes zählt geänderte Dateien, ignoriert aber Verzeichnisse mit weniger als 10 % des gesamten Anteils an geänderten Dateien und akkumuliert die Zählungen von Unterverzeichnissen in den übergeordneten Verzeichnissen: --dirstat=files,10,cumulative.

--cumulative

Synonym für --dirstat=cumulative.

--dirstat-by-file[=<param>,...]

Synonym für --dirstat=files,<param>,....

--summary

Gibt eine komprimierte Zusammenfassung von erweiterten Kopfzeileninformationen aus, wie z. B. Erstellungen, Umbenennungen und Modusänderungen.

--patch-with-stat

Synonym für -p --stat.

-z

Trennt die Commits mit NULs statt mit Zeilenumbrüchen.

Wenn --raw oder --numstat angegeben wurde, werden außerdem keine Pfadnamen verändert und NULs als Feldtrenner für die Ausgabe verwendet.

Ohne diese Option werden Pfadnamen mit "ungewöhnlichen" Zeichen gemäß der Beschreibung der Konfigurationsvariable core.quotePath (siehe git-config[1]) maskiert.

--name-only

Zeigt nur den Namen jeder geänderten Datei im Post-Image-Tree an. Die Dateinamen sind oft in UTF-8 kodiert. Weitere Informationen finden Sie in der Diskussion über die Kodierung in der Handbuchseite git-log[1].

--name-status

Zeigt nur die Namen und den Status jeder geänderten Datei an. Siehe die Beschreibung der Option --diff-filter, was die Statusbuchstaben bedeuten. Genau wie --name-only sind die Dateinamen oft in UTF-8 kodiert.

--submodule[=<format>]

Gibt an, wie Änderungen in Submodulen angezeigt werden sollen. Bei Angabe von --submodule=short wird das Format short verwendet. Dieses Format zeigt nur die Namen der Commits am Anfang und Ende des Bereichs an. Wenn --submodule oder --submodule=log angegeben wird, wird das Format log verwendet. Dieses Format listet die Commits im Bereich auf, wie es git submodule summary tut. Wenn --submodule=diff angegeben wird, wird das Format diff verwendet. Dieses Format zeigt eine Inline-Diff der Änderungen im Submodulinhalt zwischen dem Commit-Bereich an. Standardmäßig wird diff.submodule oder das Format short verwendet, wenn die Konfigurationsoption nicht gesetzt ist.

--color[=<when>]

Zeigt gefärbte Diffs an. --color (d. h. ohne =<when>) ist dasselbe wie --color=always. <when> kann einer der Werte always, never oder auto sein.

--no-color

Schaltet farbige Diffs aus. Dies ist dasselbe wie --color=never.

--color-moved[=<mode>]

Verschobene Codezeilen werden anders gefärbt. Der <mode> ist standardmäßig no, wenn die Option nicht angegeben wird, und zebra, wenn die Option ohne Modus angegeben wird. Der Modus muss einer der folgenden sein:

no: Verschobene Zeilen werden nicht hervorgehoben.
default: Ist ein Synonym für zebra. Dies kann sich in Zukunft zu einem sinnvollere Modus ändern.
plain: Jede Zeile, die an einer Stelle hinzugefügt und an einer anderen Stelle entfernt wurde, wird mit color.diff.newMoved gefärbt. Ebenso wird color.diff.oldMoved für entfernte Zeilen verwendet, die an anderer Stelle im Diff hinzugefügt wurden. Dieser Modus erkennt jede verschobene Zeile, ist aber bei der Überprüfung nicht sehr nützlich, um festzustellen, ob ein Codeblock ohne Permutation verschoben wurde.
blocks: Blöcke von verschobenem Text von mindestens 20 alphanumerischen Zeichen werden gierig erkannt. Die erkannten Blöcke werden mit der Farbe color.diff.(old|new)Moved gefärbt. Benachbarte Blöcke können nicht voneinander unterschieden werden.
zebra: Blöcke von verschobenem Text werden wie im Modus blocks erkannt. Die Blöcke werden entweder mit der Farbe color.diff.(old|new)Moved oder color.diff.(old|new)MovedAlternative gefärbt. Der Wechsel zwischen den beiden Farben zeigt an, dass ein neuer Block erkannt wurde.
dimmed-zebra: Ähnlich wie zebra, aber es wird eine zusätzliche Dämpfung uninteressanter Teile von verschobenem Code durchgeführt. Die Randlinien zweier benachbarter Blöcke gelten als interessant, der Rest als uninteressant. dimmed_zebra ist ein veraltetes Synonym.

--no-color-moved

Verschiebungserkennung ausschalten. Dies kann verwendet werden, um Konfigurationseinstellungen zu überschreiben. Es ist dasselbe wie --color-moved=no.

--color-moved-ws=<mode>,...

Dies konfiguriert, wie Leerzeichen bei der Verschiebungserkennung für --color-moved ignoriert werden. Diese Modi können als kommagetrennte Liste übergeben werden:

no: Ignoriert keine Leerzeichen bei der Verschiebungserkennung.
ignore-space-at-eol: Ignoriert Änderungen an Leerzeichen am Zeilenende.
ignore-space-change: Ignoriert Änderungen an der Leerzeichenmenge. Dies ignoriert Leerzeichen am Zeilenende und betrachtet alle anderen Sequenzen von einem oder mehreren Leerzeichen als äquivalent.
ignore-all-space: Ignoriert Leerzeichen beim Vergleich von Zeilen. Dies ignoriert Unterschiede, auch wenn eine Zeile Leerzeichen enthält, während die andere Zeile keine hat.
allow-indentation-change: Ignoriert zunächst jegliche Leerzeichen bei der Verschiebungserkennung, gruppiert dann die verschobenen Codeblöcke nur dann zu einem Block, wenn die Änderung der Leerzeichen pro Zeile gleich ist. Dies ist mit den anderen Modi nicht kompatibel.

--no-color-moved-ws

Ignoriert keine Leerzeichen bei der Verschiebungserkennung. Dies kann verwendet werden, um Konfigurationseinstellungen zu überschreiben. Es ist dasselbe wie --color-moved-ws=no.

--word-diff[=<mode>]

Standardmäßig werden Wörter durch Leerzeichen getrennt; siehe --word-diff-regex unten. Der <mode> ist standardmäßig plain und muss einer der folgenden sein:

color: Hebt geänderte Wörter nur mit Farben hervor. Beinhaltet --color.
plain: Zeigt Wörter als [-entfernt-] und {hinzugefügt}. Versucht nicht, die Begrenzer zu escapen, falls sie im Eingabetext vorkommen, daher kann die Ausgabe mehrdeutig sein.
porcelain: Verwendet ein spezielles zeilenbasiertes Format, das für die Skriptverarbeitung bestimmt ist. Hinzugefügte/entfernte/unveränderte Laufwerke werden im üblichen einheitlichen Diff-Format ausgegeben, beginnend mit einem +/-/` ` Zeichen am Anfang der Zeile und sich bis zum Ende der Zeile erstreckend. Zeilenumbrüche im Eingabetext werden durch eine Tilde ~ auf einer eigenen Zeile dargestellt.
none: Deaktiviert die Wort-Diff-Funktion erneut.

Beachten Sie, dass trotz des Namens des ersten Modus Farben verwendet werden, um die geänderten Teile in allen Modi hervorzuheben, wenn sie aktiviert sind.

--word-diff-regex=<regex>

Verwendet <regex>, um zu entscheiden, was ein Wort ist, anstatt Wortfolgen von Nicht-Leerzeichen als Wort zu betrachten. Beinhaltet auch --word-diff, es sei denn, es war bereits aktiviert.

Jede nicht überlappende Übereinstimmung des <regex> wird als Wort betrachtet. Alles zwischen diesen Übereinstimmungen wird als Leerzeichen betrachtet und ignoriert(!) für die Zwecke der Differenzfindung. Möglicherweise möchten Sie |[^[:space:]] an Ihre regulären Ausdrücke anhängen, um sicherzustellen, dass sie alle Nicht-Leerzeichen-Zeichen abdecken. Eine Übereinstimmung, die einen Zeilenumbruch enthält, wird stummgeschaltet(!) am Zeilenumbruch gekürzt.

Zum Beispiel wird --word-diff-regex=. jedes Zeichen als Wort behandeln und dementsprechend Unterschiede Zeichen für Zeichen anzeigen.

Der Regex kann auch über einen Diff-Treiber oder eine Konfigurationsoption gesetzt werden, siehe gitattributes[5] oder git-config[1]. Die explizite Angabe überschreibt jeden Diff-Treiber oder jede Konfigurationseinstellung. Diff-Treiber überschreiben Konfigurationseinstellungen.

--color-words[=<regex>]

Entspricht --word-diff=color plus (wenn ein Regex angegeben wurde) --word-diff-regex=<regex>.

--no-renames

Umbenennungserkennung deaktivieren, auch wenn die Konfigurationsdatei dies standardmäßig vorgibt.

--rename-empty

--no-rename-empty

Ob leere Blobs als Umbenennungsquelle verwendet werden sollen.

--check

Warnt, wenn Änderungen Konfliktmarkierungen oder Leerzeichenfehler einführen. Was als Leerzeichenfehler gilt, wird durch die Konfiguration core.whitespace gesteuert. Standardmäßig gelten nachgestellte Leerzeichen (einschließlich Zeilen, die nur aus Leerzeichen bestehen) und ein Leerzeichen, dem unmittelbar ein Tabulatorzeichen im anfänglichen Einzug der Zeile folgt, als Leerzeichenfehler. Beendet mit einem nicht-null-Status, wenn Probleme gefunden werden. Nicht kompatibel mit --exit-code.

--ws-error-highlight=<kind>

Hebt Leerzeichenfehler in den context-, old- oder new-Zeilen des Diffs hervor. Mehrere Werte werden durch Kommas getrennt, none setzt vorherige Werte zurück, default setzt die Liste auf new zurück und all ist eine Abkürzung für old,new,context. Wenn diese Option nicht angegeben wird und die Konfigurationsvariable diff.wsErrorHighlight nicht gesetzt ist, werden nur Leerzeichenfehler in new-Zeilen hervorgehoben. Die Leerzeichenfehler werden mit color.diff.whitespace gefärbt.

--full-index

Zeigt anstelle der ersten paar Zeichen die vollständigen Blob-Objekt-Namen vor und nach der Änderung in der "index"-Zeile an, wenn die Patch-Format-Ausgabe generiert wird.

--binary

Zusätzlich zu --full-index wird ein binärer Diff ausgegeben, der mit git-apply angewendet werden kann. Beinhaltet --patch.

--abbrev[=<n>]

Anstatt den vollständigen 40-Byte-Hexadezimalnamen eines Objekts im diff-raw-Format und in den Kopfzeilen des diff-tree-Formats anzuzeigen, wird der kürzeste Präfix angezeigt, der mindestens <n> Hexadezimalziffern lang ist und das Objekt eindeutig identifiziert. Im diff-patch-Ausgabeformat hat --full-index höhere Priorität, d.h. wenn --full-index angegeben ist, werden vollständige Blob-Namen unabhängig von --abbrev angezeigt. Eine nicht standardmäßige Anzahl von Ziffern kann mit --abbrev=<n> angegeben werden.

-B[<n>][/<m>]

--break-rewrites[=[<n>][/<m>]]

Zerlegen Sie vollständige Umschreibungsänderungen in Paare aus Löschung und Erstellung. Dies dient zwei Zwecken

Es beeinflusst die Art und Weise, wie eine Änderung, die einer vollständigen Umschreibung einer Datei entspricht, nicht als eine Reihe von Löschungen und Einfügungen, die mit sehr wenigen passenden Textzeilen als Kontext vermischt sind, sondern als eine einzelne Löschung des alten und eine einzelne Einfügung des neuen dargestellt wird. Die Zahl <m> steuert diesen Aspekt der Option -B (standardmäßig 60%). -B/70% gibt an, dass weniger als 30% des Originals im Ergebnis verbleiben müssen, damit Git dies als vollständige Umschreibung betrachtet (andernfalls wird der resultierende Patch eine Reihe von Löschungen und Einfügungen mit Kontextzeilen sein).

Wenn mit -M verwendet, wird eine vollständig umgeschriebene Datei auch als Quelle einer Umbenennung betrachtet (normalerweise betrachtet -M nur eine verschwundene Datei als Quelle einer Umbenennung). Die Zahl <n> steuert diesen Aspekt der Option -B (standardmäßig 50%). -B20% gibt an, dass eine Änderung mit Hinzufügungen und Löschungen im Verhältnis zu 20% oder mehr der Dateigröße als mögliche Quelle für eine Umbenennung in eine andere Datei in Betracht gezogen werden kann.

-M[<n>]

--find-renames[=<n>]

Wenn Diffs generiert werden, werden Umbenennungen für jeden Commit erkannt und gemeldet. Um Dateien über Umbenennungen hinweg bei der Verfolgung der Historie zu verfolgen, siehe --follow. Wenn <n> angegeben ist, ist dies ein Schwellenwert für den Ähnlichkeitsindex (d.h. die Menge an Hinzufügungen/Löschungen im Verhältnis zur Dateigröße). Zum Beispiel bedeutet -M90%, dass Git ein Lösch-/Hinzufügungspaar als Umbenennung betrachtet, wenn mehr als 90 % der Datei unverändert geblieben sind. Ohne ein %-Zeichen wird die Zahl als Bruch gelesen, mit einem Dezimalpunkt davor. D.h., -M5 wird zu 0,5 und ist somit dasselbe wie -M50%. Ähnlich ist -M05 dasselbe wie -M5%. Um die Erkennung auf exakte Umbenennungen zu beschränken, verwenden Sie -M100%. Der Standard-Ähnlichkeitsindex beträgt 50 %.

-C[<n>]

--find-copies[=<n>]

Erkennt auch Kopien sowie Umbenennungen. Siehe auch --find-copies-harder. Wenn <n> angegeben ist, hat es die gleiche Bedeutung wie bei -M<n>.

--find-copies-harder

Aus Leistungsgründen erkennt die Option -C standardmäßig Kopien nur dann, wenn die Originaldatei der Kopie im selben Änderungssatz geändert wurde. Dieses Flag bewirkt, dass der Befehl auch unveränderte Dateien als Kandidaten für die Quelle einer Kopie untersucht. Dies ist eine sehr aufwendige Operation für große Projekte, daher sollte sie mit Vorsicht verwendet werden. Die Angabe von mehr als einer -C Option hat die gleiche Wirkung.

-D

--irreversible-delete

Unterdrückt die Vorabinformationen für Löschungen, d.h. gibt nur den Header aus, aber nicht den Unterschied zwischen der Vorabinformation und /dev/null. Der resultierende Patch ist nicht dafür bestimmt, mit patch oder git apply angewendet zu werden; dies ist ausschließlich für Personen gedacht, die sich nur auf die Überprüfung des Textes nach der Änderung konzentrieren möchten. Darüber hinaus fehlen offensichtlich genügend Informationen, um einen solchen Patch umgekehrt anzuwenden, selbst manuell, daher der Name der Option.

Wenn zusammen mit -B verwendet, werden auch die Vorabinformationen im Löschteil eines Lösch-/Erstellungspaares unterdrückt.

-l<num>

Die Optionen -M und -C beinhalten einige vorbereitende Schritte, die Teilmengen von Umbenennungen/Kopien kostengünstig erkennen können, gefolgt von einem vollständigen Fallback-Teil, der alle verbleibenden ungepaarten Ziele mit allen relevanten Quellen vergleicht. (Für Umbenennungen sind nur verbleibende ungepaarte Quellen relevant; für Kopien sind alle ursprünglichen Quellen relevant.) Für N Quellen und Ziele ist dieser vollständige Vergleich O(N^2). Diese Option verhindert, dass der vollständige Teil der Umbenennungs-/Kopiererkennung ausgeführt wird, wenn die Anzahl der beteiligten Quell-/Ziel-Dateien die angegebene Zahl überschreitet. Standardmäßig wird diff.renameLimit verwendet. Beachten Sie, dass ein Wert von 0 als unbegrenzt behandelt wird.

--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]

Wählen Sie nur Dateien aus, die hinzugefügt (A), kopiert (C), gelöscht (D), geändert (M), umbenannt (R), deren Typ geändert wurde (T), die nicht zusammengeführt (U), unbekannt (X) oder deren Paarung unterbrochen wurde (B). Jede Kombination von Filterzeichen (einschließlich keiner) kann verwendet werden. Wenn * (Alles oder Nichts) zur Kombination hinzugefügt wird, werden alle Pfade ausgewählt, wenn eine Datei vorhanden ist, die anderen Kriterien im Vergleich entspricht; wenn keine Datei vorhanden ist, die anderen Kriterien entspricht, wird nichts ausgewählt.

Außerdem können diese Großbuchstaben kleingeschrieben werden, um auszuschließen. Z.B. schließt --diff-filter=ad hinzugefügte und gelöschte Pfade aus.

Beachten Sie, dass nicht alle Diffs alle Typen enthalten können. Kopierte und umbenannte Einträge können beispielsweise nicht erscheinen, wenn die Erkennung für diese Typen deaktiviert ist.

-S<string>

Sucht nach Unterschieden, die die Anzahl der Vorkommen des angegebenen <string> (d.h. Hinzufügung/Löschung) in einer Datei ändern. Gedacht für den Gebrauch durch Skripte.

Es ist nützlich, wenn Sie nach einem exakten Codeblock (wie einer Struktur) suchen und die Historie dieses Blocks seit seiner Entstehung erfahren möchten: Verwenden Sie die Funktion iterativ, um den interessanten Block aus der Vorabinformation zurück in -S einzuspeisen und fahren Sie fort, bis Sie die allererste Version des Blocks erhalten.

Binärdateien werden ebenfalls durchsucht.

-G<regex>

Sucht nach Unterschieden, deren Patch-Text hinzugefügte/entfernte Zeilen enthält, die mit <regex> übereinstimmen.

Um den Unterschied zwischen -S<regex> --pickaxe-regex und -G<regex> zu verdeutlichen, betrachten Sie einen Commit mit dem folgenden Diff in derselben Datei

+    return frotz(nitfol, two->ptr, 1, 0);
...
-    hit = frotz(nitfol, mf2.ptr, 1, 0);

Während git log -G"frotz\(nitfol" diesen Commit anzeigt, git log -S"frotz\(nitfol" --pickaxe-regex nicht (da sich die Anzahl der Vorkommen dieses Strings nicht geändert hat).

Sofern --text nicht angegeben ist, werden Patches von Binärdateien ohne Textkonvertierungsfilter ignoriert.

Weitere Informationen finden Sie im Eintrag pickaxe in gitdiffcore[7].

--find-object=<object-id>

Sucht nach Unterschieden, die die Anzahl der Vorkommen des angegebenen Objekts ändern. Ähnlich wie bei -S, nur dass sich das Argument unterscheidet, da es nicht nach einem bestimmten String, sondern nach einer bestimmten Objekt-ID sucht.

Das Objekt kann ein Blob oder ein Submodul-Commit sein. Es impliziert die Option -t in git-log, um auch Bäume zu finden.

--pickaxe-all

Wenn -S oder -G eine Änderung findet, werden alle Änderungen in diesem Änderungssatz angezeigt, nicht nur die Dateien, die die Änderung am <string> enthalten.

--pickaxe-regex

Behandelt den an -S übergebenen <string> als erweiterte POSIX-regulären Ausdruck zur Übereinstimmung.

-O<orderfile>

Steuert die Reihenfolge, in der Dateien in der Ausgabe erscheinen. Dies überschreibt die Konfigurationsvariable diff.orderFile (siehe git-config[1]). Um diff.orderFile abzubrechen, verwenden Sie -O/dev/null.

Die Ausgabereihenfolge wird durch die Reihenfolge der Glob-Muster in <orderfile> bestimmt. Alle Dateien mit Pfadnamen, die mit dem ersten Muster übereinstimmen, werden zuerst ausgegeben, alle Dateien mit Pfadnamen, die mit dem zweiten Muster (aber nicht mit dem ersten) übereinstimmen, werden als nächstes ausgegeben, und so weiter. Alle Dateien mit Pfadnamen, die keinem Muster entsprechen, werden zuletzt ausgegeben, als ob ein implizites Muster für alles am Ende der Datei stünde. Wenn mehrere Pfadnamen den gleichen Rang haben (sie stimmen mit demselben Muster, aber keinen früheren Mustern überein), ist ihre relative Ausgabereihenfolge die normale.

<orderfile> wird wie folgt analysiert

Leere Zeilen werden ignoriert und können als Trennzeichen zur besseren Lesbarkeit verwendet werden.
Zeilen, die mit einem Hash ("#") beginnen, werden ignoriert, sodass sie für Kommentare verwendet werden können. Fügen Sie einen Backslash ("\") am Anfang des Musters hinzu, wenn es mit einem Hash beginnt.
Jede andere Zeile enthält ein einzelnes Muster.

Muster haben die gleiche Syntax und Semantik wie Muster, die für fnmatch(3) ohne das Flag FNM_PATHNAME verwendet werden, mit der Ausnahme, dass ein Pfadname auch dann mit einem Muster übereinstimmt, wenn das Entfernen einer beliebigen Anzahl der letzten Pfadkomponenten mit dem Muster übereinstimmt. Zum Beispiel passt das Muster "foo*bar" auf "fooasdfbar" und "foo/bar/baz/asdf", aber nicht auf "foobarx".

--skip-to=<file>

--rotate-to=<file>

Verwerfen Sie die Dateien vor der benannten <file> aus der Ausgabe (d.h. skip to) oder verschieben Sie sie ans Ende der Ausgabe (d.h. rotate to). Diese Optionen wurden hauptsächlich für die Verwendung des Befehls git difftool entwickelt und sind möglicherweise sonst nicht sehr nützlich.

-R

Vertauschen Sie zwei Eingaben; d.h., zeigen Sie Unterschiede vom Index oder der Festplattendatei zu Baum-Inhalten an.

--relative[=<path>]

--no-relative

Wenn von einem Unterverzeichnis des Projekts aus ausgeführt, kann es angewiesen werden, Änderungen außerhalb des Verzeichnisses auszuschließen und Pfadnamen relativ dazu mit dieser Option anzuzeigen. Wenn Sie sich nicht in einem Unterverzeichnis befinden (z.B. in einem Bare-Repository), können Sie angeben, welches Unterverzeichnis die Ausgabe relativ dazu machen soll, indem Sie <path> als Argument angeben. --no-relative kann verwendet werden, um sowohl die Konfigurationsoption diff.relative als auch die vorherige Option --relative zu widerrufen.

-a

--text

Behandeln Sie alle Dateien als Text.

--ignore-cr-at-eol

Ignoriert Wagenrücklauf am Zeilenende beim Vergleichen.

--ignore-space-at-eol

Ignoriert Änderungen an Leerzeichen am Zeilenende.

-b

--ignore-space-change

Ignoriert Änderungen an der Leerzeichenmenge. Dies ignoriert Leerzeichen am Zeilenende und betrachtet alle anderen Sequenzen von einem oder mehreren Leerzeichen als äquivalent.

-w

--ignore-all-space

Ignoriert Leerzeichen beim Vergleich von Zeilen. Dies ignoriert Unterschiede, auch wenn eine Zeile Leerzeichen enthält, während die andere Zeile keine hat.

--ignore-blank-lines

Ignoriert Änderungen, deren Zeilen alle leer sind.

-I<regex>

--ignore-matching-lines=<regex>

Ignoriert Änderungen, deren alle Zeilen mit <regex> übereinstimmen. Diese Option kann mehr als einmal angegeben werden.

--inter-hunk-context=<number>

Zeigt den Kontext zwischen Diff-Hunks bis zur angegebenen Anzahl von <n> Zeilen an und fasst so nahe beieinander liegende Hunks zusammen. Standard ist diff.interHunkContext oder 0, wenn die Konfigurationsoption nicht gesetzt ist.

-W

--function-context

Zeigt die gesamte Funktion als Kontextzeilen für jede Änderung an. Die Funktionsnamen werden auf die gleiche Weise bestimmt, wie git diff Patch-Hunk-Header erstellt (siehe "Defining a custom hunk-header" in gitattributes[5]).

--ext-diff

Ermöglicht die Ausführung eines externen Diff-Helferprogramms. Wenn Sie einen externen Diff-Treiber mit gitattributes[5] einrichten, müssen Sie diese Option mit git-log[1] und ähnlichen Befehlen verwenden.

--no-ext-diff

Deaktiviert externe Diff-Treiber.

--textconv

--no-textconv

Erlaubt (oder verbietet) die Ausführung externer Textkonvertierungsfilter beim Vergleichen von Binärdateien. Siehe gitattributes[5] für Details. Da Textkonvertierungsfilter typischerweise eine unidirektionale Konvertierung sind, ist der resultierende Diff für den menschlichen Gebrauch geeignet, kann aber nicht angewendet werden. Aus diesem Grund sind Textkonvertierungsfilter standardmäßig nur für git-diff[1] und git-log[1] aktiviert, aber nicht für git-format-patch[1] oder Diff-Plumbing-Befehle.

--ignore-submodules[=(none|untracked|dirty|all)]

Ignoriert Änderungen an Submodulen bei der Diff-Generierung. all ist der Standardwert. Die Verwendung von none betrachtet das Submodul als modifiziert, wenn es ungetrackte oder modifizierte Dateien enthält oder wenn sein HEAD vom Commit im Superprojekt abweicht, und kann verwendet werden, um jegliche Einstellungen der Option ignore in git-config[1] oder gitmodules[5] zu überschreiben. Wenn untracked verwendet wird, werden Submodule nicht als "dirty" betrachtet, wenn sie nur ungetrackten Inhalt enthalten (sie werden aber weiterhin auf modifizierten Inhalt gescannt). Die Verwendung von dirty ignoriert alle Änderungen am Arbeitsverzeichnis von Submodulen; nur Änderungen an den im Superprojekt gespeicherten Commits werden angezeigt (dies war das Verhalten bis 1.7.0). Die Verwendung von all blendet alle Änderungen an Submodulen aus.

--src-prefix=<prefix>

Zeigt den angegebenen Quell-<prefix> anstelle von "a/" an.

--dst-prefix=<prefix>

Zeigt den angegebenen Ziel-<prefix> anstelle von "b/" an.

--no-prefix

Zeigt keine Quell- oder Zielpräfixe an.

--default-prefix

Verwendet die Standard-Quell- und Zielpräfixe ("a/" und "b/"). Dies überschreibt Konfigurationsvariablen wie diff.noprefix, diff.srcPrefix, diff.dstPrefix und diff.mnemonicPrefix (siehe git-config[1]).

--line-prefix=<prefix>

Fügt jeder Zeile der Ausgabe einen zusätzlichen <prefix> voran.

--ita-invisible-in-index

Standardmäßig erscheinen Einträge, die mit git add -N hinzugefügt wurden, als existierende leere Datei in git diff und als neue Datei in git diff --cached. Diese Option bewirkt, dass der Eintrag als neue Datei in git diff und als nicht vorhanden in git diff --cached erscheint. Diese Option kann mit --ita-visible-in-index rückgängig gemacht werden. Beide Optionen sind experimentell und können in zukünftigen Versionen entfernt werden.

--max-depth=<Tiefe>

Für jeden auf der Kommandozeile angegebenen Pfadspec wird maximal bis zur Tiefe von <depth> Ebenen von Verzeichnissen abgestiegen. Ein Wert von -1 bedeutet keine Begrenzung. Kann nicht mit Wildcards im Pfadspec kombiniert werden. Bei einem Baum, der foo/bar/baz enthält, zeigt die folgende Liste die Übereinstimmungen, die von jeder Optionsmenge generiert werden

--max-depth=0 -- foo: foo
--max-depth=1 -- foo: foo/bar
--max-depth=1 -- foo/bar: foo/bar/baz
--max-depth=1 -- foo foo/bar: foo/bar/baz
--max-depth=2 -- foo: foo/bar/baz

Wenn kein Pfadspec angegeben ist, wird die Tiefe gemessen, als ob alle Top-Level-Einträge angegeben wären. Beachten Sie, dass dies anders ist, als von der Wurzel aus zu messen, da --max-depth=0 immer noch foo zurückgeben würde. Dies ermöglicht es Ihnen, die Tiefe weiterhin zu begrenzen, während Sie eine Teilmenge der Top-Level-Einträge anfordern.

Beachten Sie, dass diese Option nur für Diffs zwischen Baum-Objekten unterstützt wird, nicht gegen den Index oder den Arbeitsbaum.

Für eine detailliertere Erklärung dieser gängigen Optionen siehe auch gitdiffcore[7].

Patch-Text mit -p generieren

Das Ausführen von git-diff[1], git-log[1], git-show[1], git-diff-index[1], git-diff-tree[1] oder git-diff-files[1] mit der Option -p erzeugt Patch-Text. Sie können die Erstellung von Patch-Text über die Umgebungsvariablen GIT_EXTERNAL_DIFF und GIT_DIFF_OPTS (siehe git[1]) sowie das Attribut diff (siehe gitattributes[5]) anpassen.

Was die Option -p erzeugt, unterscheidet sich geringfügig vom traditionellen Diff-Format

Es wird eine "git diff"-Kopfzeile vorangestellt, die wie folgt aussieht
```
diff --git a/file1 b/file2
```
Die Dateinamen a/ und b/ sind gleich, es sei denn, Umbenennung/Kopie ist beteiligt. Insbesondere wird selbst bei einer Erstellung oder Löschung /dev/null *nicht* anstelle der Dateinamen a/ oder b/ verwendet.

Wenn eine Umbenennung/Kopie beteiligt ist, zeigen file1 und file2 den Namen der Quelldatei der Umbenennung/Kopie und den Namen der Datei an, die die Umbenennung/Kopie erzeugt, bzw.
Es folgen eine oder mehrere erweiterte Kopfzeilen
```
old mode <mode>
new mode <mode>
deleted file mode <mode>
new file mode <mode>
copy from <path>
copy to <path>
rename from <path>
rename to <path>
similarity index <number>
dissimilarity index <number>
index <hash>..<hash> <mode>
```
Dateimodus <mode> wird als 6-stellige Oktalzahlen einschließlich des Dateityps und der Dateiberechtigungsbits ausgegeben.

Pfadnamen in erweiterten Kopfzeilen enthalten nicht die Präfixe a/ und b/.

Der Ähnlichkeitsindex ist der Prozentsatz unveränderter Zeilen, und der Unähnlichkeitsindex ist der Prozentsatz geänderter Zeilen. Es handelt sich um eine abgerundete Ganzzahl, gefolgt von einem Prozentzeichen. Der Ähnlichkeitsindex von 100% ist also für zwei gleiche Dateien reserviert, während 100% Unähnlichkeit bedeutet, dass keine Zeile aus der alten Datei in die neue gelangt ist.

Die Indexzeile enthält die Blob-Objektnamen vor und nach der Änderung. Der <mode> wird angegeben, wenn sich der Dateimodus nicht ändert; andernfalls geben separate Zeilen den alten und den neuen Modus an.
Pfadnamen mit "ungewöhnlichen" Zeichen werden wie für die Konfigurationsvariable core.quotePath erklärt zitiert (siehe git-config[1]).
Alle file1-Dateien in der Ausgabe beziehen sich auf Dateien vor dem Commit, und alle file2-Dateien beziehen sich auf Dateien nach dem Commit. Es ist falsch, jede Änderung sequenziell auf jede Datei anzuwenden. Dieser Patch vertauscht zum Beispiel a und b
```
diff --git a/a b/b
rename from a
rename to b
diff --git a/b b/a
rename from b
rename to a
```
Hunk-Kopfzeilen erwähnen den Namen der Funktion, auf die sich der Hunk bezieht. Siehe "Defining a custom hunk-header" in gitattributes[5] für Details, wie dies für bestimmte Sprachen angepasst werden kann.

Kombiniertes Diff-Format

Jeder diff-generierende Befehl kann die Option -c oder --cc verwenden, um einen kombinierten Diff bei der Anzeige eines Merges zu erzeugen. Dies ist das Standardformat bei der Anzeige von Merges mit git-diff[1] oder git-show[1]. Beachten Sie auch, dass Sie jeder dieser Befehle eine geeignete Option --diff-merges geben können, um die Generierung von Diffs in einem bestimmten Format zu erzwingen.

Ein "kombiniertes Diff"-Format sieht wie folgt aus

diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
	return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
  }

- static void describe(char *arg)
 -static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
  {
 +	unsigned char sha1[20];
 +	struct commit *cmit;
	struct commit_list *list;
	static int initialized = 0;
	struct commit_name *n;

 +	if (get_sha1(arg, sha1) < 0)
 +		usage(describe_usage);
 +	cmit = lookup_commit_reference(sha1);
 +	if (!cmit)
 +		usage(describe_usage);
 +
	if (!initialized) {
		initialized = 1;
		for_each_ref(get_name);

Es wird eine "git diff"-Kopfzeile vorangestellt, die wie folgt aussieht (wenn die Option -c verwendet wird)
```
diff --combined file
```
oder wie folgt (wenn die Option --cc verwendet wird)
```
diff --cc file
```
Es folgen eine oder mehrere erweiterte Kopfzeilen (dieses Beispiel zeigt einen Merge mit zwei Elternteilen)
```
index <hash>,<hash>..<hash>
mode <mode>,<mode>..<mode>
new file mode <mode>
deleted file mode <mode>,<mode>
```
Die Zeile mode <mode>,<mode>..<mode> erscheint nur, wenn mindestens einer der <mode> sich vom Rest unterscheidet. Erweiterte Kopfzeilen mit Informationen über erkannte Inhaltsbewegungen (Umbenennungen und Kopiererkennung) sind für die Diff-Erstellung von zwei <tree-ish> konzipiert und werden nicht für das kombinierte Diff-Format verwendet.
Es folgt eine Zwei-Zeilen-Kopfzeile für von-Datei/zu-Datei
```
--- a/file
+++ b/file
```
Ähnlich der Zwei-Zeilen-Kopfzeile für das traditionelle einheitliche Diff-Format wird /dev/null verwendet, um erstellte oder gelöschte Dateien zu signalisieren.

Wenn jedoch die Option --combined-all-paths bereitgestellt wird, erhalten Sie anstelle einer Zwei-Zeilen-Von-Datei/Zu-Datei-Kopfzeile eine N+1-Zeilen-Von-Datei/Zu-Datei-Kopfzeile, wobei N die Anzahl der Elternteile im Merge-Commit ist
```
--- a/file
--- a/file
--- a/file
+++ b/file
```
Dieses erweiterte Format kann nützlich sein, wenn die Umbenennungs- oder Kopiererkennung aktiv ist, damit Sie den ursprünglichen Namen der Datei in verschiedenen Elternteilen sehen können.
Die Chunk-Kopfzeile ist modifiziert, um zu verhindern, dass Leute sie versehentlich an patch -p1 weitergeben. Das kombinierte Diff-Format wurde für die Überprüfung von Merge-Commit-Änderungen erstellt und war nicht für die Anwendung gedacht. Die Änderung ist ähnlich der Änderung in der erweiterten Index-Kopfzeile
```
@@@ <from-file-range> <from-file-range> <to-file-range> @@@
```
Es gibt (Anzahl der Elternteile + 1) @-Zeichen in der Chunk-Kopfzeile für das kombinierte Diff-Format.

Im Gegensatz zum traditionellen einheitlichen Diff-Format, das zwei Dateien A und B mit einer einzelnen Spalte mit - (Minus – erscheint in A, aber entfernt in B), + (Plus – fehlt in A, aber zu B hinzugefügt) oder " " (Leerzeichen – unverändert) Präfix anzeigt, vergleicht dieses Format zwei oder mehr Dateien file1, file2,... mit einer Datei X und zeigt, wie sich X von jeder fileN unterscheidet. Eine Spalte für jede fileN wird der Ausgabenzeile vorangestellt, um zu vermerken, wie sich die Zeile von X von ihr unterscheidet.

Ein --Zeichen in Spalte N bedeutet, dass die Zeile in fileN vorkommt, aber nicht im Ergebnis. Ein +-Zeichen in Spalte N bedeutet, dass die Zeile im Ergebnis vorkommt und fileN diese Zeile nicht hat (mit anderen Worten, die Zeile wurde hinzugefügt, aus der Sicht dieses Elternteils).

Im obigen Beispiel-Output wurde die Funktionssignatur von beiden Dateien geändert (daher zwei --Entfernungen von beiden file1 und file2, plus ++, was bedeutet, dass eine hinzugefügte Zeile weder in file1 noch in file2 vorkommt). Außerdem sind acht andere Zeilen von file1 gleich, erscheinen aber nicht in file2 (daher mit + präfigiert).

Wenn von git diff-tree -c angezeigt, vergleicht es die Eltern eines Merge-Commits mit dem Merge-Ergebnis (d.h. file1..fileN sind die Eltern). Wenn von git diff-files -c angezeigt, vergleicht es die beiden unaufgelösten Eltern-Merges mit der Arbeitsbaumdatei (d.h. file1 ist Stage 2 aka "unsere Version", file2 ist Stage 3 aka "ihre Version").

BEISPIELE

git log --no-merges: Zeigt die gesamte Commit-Historie an, überspringt jedoch alle Merges.
git log v2.6.12.. include/scsi drivers/scsi: Zeigt alle Commits seit Version v2.6.12 an, die eine Datei im Unterverzeichnis include/scsi oder drivers/scsi geändert haben.
git log --since="2 weeks ago" -- gitk: Zeigt die Änderungen an der Datei gitk während der letzten zwei Wochen an. Der `--` ist notwendig, um Verwechslungen mit dem **Branch** namens gitk zu vermeiden.
git log --name-status release..test: Zeigt die Commits an, die im "test"-Branch vorhanden, aber noch nicht im "release"-Branch sind, zusammen mit der Liste der Pfade, die jeder Commit modifiziert.
git log --follow builtin/rev-list.c: Zeigt die Commits an, die builtin/rev-list.c geändert haben, einschließlich der Commits, die auftraten, bevor die Datei ihren jetzigen Namen erhielt.
git log --branches --not --remotes=origin: Zeigt alle Commits an, die in irgendeinem lokalen Branch, aber nicht in irgendeinem Remote-Tracking-Branch für origin vorhanden sind (was Sie haben, was origin nicht hat).
git log master --not --remotes=*/master: Zeigt alle Commits an, die im lokalen master-Branch, aber nicht in irgendeinem Remote-master-Branch vorhanden sind.
git log -p -m --first-parent: Zeigt die Historie einschließlich der Änderungs-Diffs an, aber nur aus der Perspektive des "Hauptzweigs", überspringt Commits von zusammengeführten Zweigen und zeigt vollständige Diff-Informationen zu den durch die Merges eingeführten Änderungen. Dies ist nur sinnvoll, wenn eine strikte Politik zur Zusammenführung aller Topic-Zweige auf einem einzigen Integrationszweig eingehalten wird.
git log -L /int main/',/^}/:main.c: Zeigt, wie die Funktion main() in der Datei main.c im Laufe der Zeit entwickelt wurde.
git log -3: Beschränkt die Anzahl der anzuzeigenden Commits auf 3.

DISKUSSION

Git ist bis zu einem gewissen Grad zeichenkodierungsunabhängig.

Der Inhalt der Blob-Objekte sind uninterpretierte Bytefolgen. Auf Kern-Ebene erfolgt keine Kodierungsumwandlung.
Pfadnamen werden in UTF-8 Normalisierungsform C kodiert. Dies gilt für Baum-Objekte, die Indexdatei, Ref-Namen sowie für Pfadnamen in Kommandozeilenargumenten, Umgebungsvariablen und Konfigurationsdateien (.git/config (siehe git-config[1]), gitignore[5], gitattributes[5] und gitmodules[5]).

Beachten Sie, dass Git auf Kern-Ebene Pfadnamen einfach als Folgen von Nicht-NUL-Bytes behandelt, es gibt keine Pfadnamen-Kodierungskonvertierungen (außer unter Mac und Windows). Daher funktionieren nicht-ASCII-Pfadnamen meist auch auf Plattformen und Dateisystemen, die Legacy-Erweiterte-ASCII-Kodierungen verwenden. Repositories, die auf solchen Systemen erstellt wurden, funktionieren jedoch nicht ordnungsgemäß auf UTF-8-basierten Systemen (z. B. Linux, Mac, Windows) und umgekehrt. Zusätzlich gehen viele Git-basierte Werkzeuge einfach davon aus, dass Pfadnamen UTF-8 sind und werden andere Kodierungen nicht korrekt anzeigen.
Commit-Log-Nachrichten sind typischerweise in UTF-8 kodiert, aber auch andere erweiterte ASCII-Kodierungen werden unterstützt. Dazu gehören ISO-8859-x, CP125x und viele andere, aber *nicht* UTF-16/32, EBCDIC und CJK-Multibyte-Kodierungen (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).

Obwohl wir ermutigen, dass die Commit-Log-Nachrichten in UTF-8 kodiert werden, sind sowohl der Kern als auch Git Porcelain so konzipiert, dass sie Projekten keine UTF-8 aufzwingen. Wenn alle Teilnehmer eines bestimmten Projekts es bequemer finden, Legacy-Kodierungen zu verwenden, verbietet Git dies nicht. Es gibt jedoch ein paar Dinge zu beachten.

git commit und git commit-tree geben eine Warnung aus, wenn die ihnen übergebene Commit-Log-Nachricht keine gültige UTF-8-Zeichenkette zu sein scheint, es sei denn, Sie geben explizit an, dass Ihr Projekt eine Legacy-Kodierung verwendet. Dies geschieht durch Festlegen von i18n.commitEncoding in der Datei .git/config, wie folgt
```
[i18n]
	commitEncoding = ISO-8859-1
```
Mit der obigen Einstellung erstellte Commit-Objekte speichern den Wert von i18n.commitEncoding in ihrer encoding-Kopfzeile. Dies soll anderen Personen helfen, die sie später betrachten. Das Fehlen dieser Kopfzeile impliziert, dass die Commit-Log-Nachricht in UTF-8 kodiert ist.
git log, git show, git blame und Freunde betrachten den encoding Header eines Commit-Objekts und versuchen, die Log-Nachricht in UTF-8 neu zu kodieren, sofern nicht anders angegeben. Sie können die gewünschte Ausgabe-Kodierung mit i18n.logOutputEncoding in der .git/config-Datei angeben, wie folgt:
```
[i18n]
	logOutputEncoding = ISO-8859-1
```
Wenn Sie diese Konfigurationsvariable nicht haben, wird stattdessen der Wert von i18n.commitEncoding verwendet.

Beachten Sie, dass wir uns bewusst entschieden haben, die Commit-Log-Nachricht nicht neu zu kodieren, wenn ein Commit durchgeführt wird, um UTF-8 auf der Ebene des Commit-Objekts zu erzwingen, da die Neukodierung nach UTF-8 nicht unbedingt eine reversible Operation ist.

KONFIGURATION

Siehe git-config[1] für Kernvariablen und git-diff[1] für Einstellungen im Zusammenhang mit der Diff-Generierung.

format.pretty: Standardwert für die Option --format. (Siehe Pretty Formats oben.) Standardmäßig medium.
i18n.logOutputEncoding: Encoding, das beim Anzeigen von Logs verwendet wird. (Siehe Diskussion oben.) Standardmäßig wird der Wert von i18n.commitEncoding verwendet, falls gesetzt, ansonsten UTF-8.

Alles oberhalb dieser Zeile in diesem Abschnitt ist nicht in der Dokumentation von git-config[1] enthalten. Der nachfolgende Inhalt ist derselbe wie dort zu finden.

log.abbrevCommit

Wenn true, gehen git-log[1], git-show[1] und git-whatchanged[1] davon aus, dass --abbrev-commit verwendet wird. Sie können diese Option mit --no-abbrev-commit überschreiben.

log.date

Legt den Standard-Datums-/Zeitmodus für den Befehl log fest. Das Setzen eines Wertes für log.date ähnelt der Verwendung der Option --date von git-log[1]. Siehe git-log[1] für Details.

Wenn das Format auf "auto:foo" gesetzt ist und der Pager verwendet wird, wird das Format "foo" für das Datumsformat verwendet. Andernfalls wird "default" verwendet.

log.decorate

Gibt die Referenznamen aller Commits aus, die vom Log-Befehl angezeigt werden. Mögliche Werte sind:

short: Die Präfixe der Referenznamen refs/heads/, refs/tags/ und refs/remotes/ werden nicht gedruckt.
full: Der vollständige Referenzname (einschließlich Präfix) wird gedruckt.
auto: Wenn die Ausgabe an ein Terminal geht, werden die Referenznamen angezeigt, als ob short verwendet worden wäre, ansonsten werden keine Referenznamen angezeigt.

Dies ist identisch mit der Option --decorate von git log.

log.initialDecorationSet

Standardmäßig zeigt git log nur Dekorationen für bestimmte bekannte Referenz-Namespaces an. Wenn all angegeben wird, werden alle Referenzen als Dekorationen angezeigt.

log.excludeDecoration

Schließt die angegebenen Muster von den Log-Dekorationen aus. Dies ähnelt der Kommandozeilenoption --decorate-refs-exclude, aber die Konfigurationsoption kann durch die Option --decorate-refs überschrieben werden.

log.diffMerges

Legt das Diff-Format fest, das verwendet wird, wenn --diff-merges=on angegeben ist. Siehe --diff-merges in git-log[1] für Details. Standardmäßig separate.

log.follow

Wenn true, verhält sich git log so, als ob die Option --follow verwendet worden wäre, wenn ein einzelner <Pfad> angegeben wird. Dies hat dieselben Einschränkungen wie --follow, d.h. es kann nicht zum Verfolgen mehrerer Dateien verwendet werden und funktioniert nicht gut mit nicht-linearer Historie.

log.graphColors

Eine Liste von Farben, durch Kommas getrennt, die zum Zeichnen von Historienlinien in git log --graph verwendet werden können.

log.showRoot

Wenn true, wird der initiale Commit als großes Erstellungsereignis angezeigt. Dies entspricht einem Diff gegen einen leeren Baum. Tools wie git-log[1] oder git-whatchanged[1], die normalerweise den Root-Commit ausblenden, werden ihn nun anzeigen. Standardmäßig true.

log.showSignature

Wenn true, gehen git-log[1], git-show[1] und git-whatchanged[1] davon aus, dass --show-signature verwendet wird.

log.mailmap

Wenn true, gehen git-log[1], git-show[1] und git-whatchanged[1] davon aus, dass --use-mailmap verwendet wird, andernfalls --no-use-mailmap. Standardmäßig true.

notes.mergeStrategy

Welche Merge-Strategie standardmäßig bei der Auflösung von Notizen-Konflikten gewählt werden soll. Muss einer der Werte manual, ours, theirs, union oder cat_sort_uniq sein. Standardmäßig manual. Siehe den Abschnitt "NOTES MERGE STRATEGIES" in git-notes[1] für weitere Informationen zu jeder Strategie.

Diese Einstellung kann durch Übergabe der Option --strategy an git-notes[1] überschrieben werden.

notes.<name>.mergeStrategy

Welche Merge-Strategie bei einem Notizen-Merge in refs/notes/<name> gewählt werden soll. Dies überschreibt die allgemeinere Einstellung notes.mergeStrategy. Siehe den Abschnitt "NOTES MERGE STRATEGIES" in git-notes[1] für weitere Informationen zu den verfügbaren Strategien.

notes.displayRef

Welcher Ref (oder welche Refs, wenn ein Glob oder mehrfach angegeben), zusätzlich zu dem von core.notesRef oder GIT_NOTES_REF standardmäßig festgelegten Ref, aus dem Notizen gelesen werden sollen, wenn Commit-Nachrichten mit der git log-Befehlsfamilie angezeigt werden.

Diese Einstellung kann mit der Umgebungsvariable GIT_NOTES_DISPLAY_REF überschrieben werden, die eine durch Doppelpunkte getrennte Liste von Refs oder Globs sein muss.

Für nicht existierende Refs wird eine Warnung ausgegeben, ein Glob, der keine Refs findet, wird jedoch stillschweigend ignoriert.

Diese Einstellung kann durch die Option --no-notes für die git log-Befehlsfamilie oder durch die Option --notes=<ref>, die von diesen Befehlen akzeptiert wird, deaktiviert werden.

Der effektive Wert von core.notesRef (möglicherweise überschrieben durch GIT_NOTES_REF) wird ebenfalls implizit zur Liste der anzuzeigenden Refs hinzugefügt.

notes.rewrite.<command>

Beim Umschreiben von Commits mit <command> (derzeit amend oder rebase), wenn diese Variable auf false gesetzt ist, kopiert Git keine Notizen vom Original auf den umgeschriebenen Commit. Standardmäßig true. Siehe auch notes.rewriteRef unten.

Diese Einstellung kann mit der Umgebungsvariable GIT_NOTES_REWRITE_REF überschrieben werden, die eine durch Doppelpunkte getrennte Liste von Refs oder Globs sein muss.

notes.rewriteMode

Beim Kopieren von Notizen während eines Rewrites (siehe notes.rewrite.<command>-Option) wird festgelegt, was zu tun ist, wenn der Ziel-Commit bereits eine Notiz hat. Muss einer der Werte overwrite, concatenate, cat_sort_uniq oder ignore sein. Standardmäßig concatenate.

Diese Einstellung kann mit der Umgebungsvariable GIT_NOTES_REWRITE_MODE überschrieben werden.

notes.rewriteRef

Beim Kopieren von Notizen während eines Rewrites wird der (vollqualifizierte) Ref angegeben, dessen Notizen kopiert werden sollen. Kann ein Glob sein, in diesem Fall werden Notizen aus allen passenden Refs kopiert. Sie können diese Konfiguration auch mehrmals angeben.

Hat keinen Standardwert; Sie müssen diese Variable konfigurieren, um Notizen-Rewriting zu aktivieren. Setzen Sie sie auf refs/notes/commits, um das Rewriting für die Standard-Commit-Notizen zu aktivieren.

Kann mit der Umgebungsvariable GIT_NOTES_REWRITE_REF überschrieben werden. Siehe notes.rewrite.<command> oben für eine weitere Beschreibung seines Formats.

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