Git

git-show zuletzt aktualisiert in 2.52.0

NAME

git-show - Zeigt verschiedene Objekttypen an

SYNOPSIS

git show [<options>] [<object>…]

BESCHREIBUNG

Zeigt ein oder mehrere Objekte (blobs, trees, tags und commits) an.

Für Commits werden die Log-Nachricht und der Text-Diff angezeigt. Auch Merge-Commits werden in einem speziellen Format dargestellt, wie es von git diff-tree --cc erzeugt wird.

Für Tags werden die Tag-Nachricht und die referenzierten Objekte angezeigt.

Für Trees werden die Namen angezeigt (entspricht git ls-tree --name-only).

Für einfache Blobs wird der reine Inhalt angezeigt.

Einige Optionen, die der git log Befehl versteht, können verwendet werden, um zu steuern, wie die vom Commit eingeführten Änderungen angezeigt werden.

Diese Handbuchseite beschreibt nur die am häufigsten verwendeten Optionen.

OPTIONEN

<Objekt>…

Die Namen der anzuzeigenden Objekte (standardmäßig HEAD). Eine vollständigere Liste der Möglichkeiten, Objektnamen zu schreiben, finden Sie im Abschnitt "SPECIFYING REVISIONS" in gitrevisions[7].

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

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 %
  
  %x gefolgt von zwei Hexadezimalziffern wird durch ein Byte mit dem Wert der Hexadezimalziffern ersetzt (wir nennen dies im Folgenden "Literal-Formatcode").
  
  % 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(<Spezifikation>)
  
  Farbspezifikation, wie unter "Werte" im Abschnitt "KONFIGURATIONSDATEI" 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 der ersteren, wenn wir zu einem Terminal gehen). %C(auto,<Spezifikation>) wird als historisches Synonym für die Standardeinstellung akzeptiert (z.B. %C(auto,rot)). Die Angabe von %C(always,<Spezifikation>) zeigt die Farben auch dann an, wenn Farbe nicht anderweitig aktiviert ist (obwohl man auch einfach --color=always verwenden könnte, um Farbe für die gesamte Ausgabe zu aktivieren, einschließlich dieses Formats und allem anderen, was Git einfärben könnte). auto allein (d.h. %C(auto)) aktiviert die automatische Farbgebung für die nächsten Platzhalter, 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

Die folgenden Optionen können verwendet werden, um die Art und Weise zu ändern, wie git show Diff-Ausgaben generiert.

-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. Abkürzung für --diff-merges=combined -p.

--cc

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

--dd

Erzeugt einen Diff in Bezug auf den ersten Elternteil für sowohl Merge- als auch reguläre Commits. Abkürzung für --diff-merges=first-parent -p.

--remerge-diff

Erzeugt eine remerge-diff-Ausgabe für Merge-Commits. Abkürzung für --diff-merges=remerge -p.

--no-diff-merges

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

--diff-merges=<format>

Legt das für Merge-Commits zu verwendende Diff-Format fest. Standard ist `dense-combined`, 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 einen impliziten Wert 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 Elternteil an. Dies ist dasselbe Format, das --patch für Nicht-Merge-Commits erzeugt.
separate: Zeigt den vollständigen Diff in Bezug auf jeden der Elternteile an. Für jeden Elternteil wird ein separater Log-Eintrag und Diff generiert.
combined
c: Zeigt Unterschiede von jedem der Elternteile zum Merge-Ergebnis gleichzeitig an, anstatt paarweise Unterschiede zwischen einem Elternteil und dem Ergebnis nacheinander anzuzeigen. Darüber hinaus werden nur Dateien aufgeführt, die von allen Elternteilen geändert wurden.
dense-combined
cc: Komprimiert die von --diff-merges=combined erzeugte Ausgabe weiter, indem uninteressante Hunks weggelassen werden, deren Inhalte in den Elternteilen nur zwei Varianten aufweisen und das Merge-Ergebnis eine davon ohne Änderung übernimmt.
remerge
r: Führt eine Remerge von Zwei-Elternteil-Merge-Commits durch, um ein temporäres Baumobjekt zu erstellen – möglicherweise mit Dateien mit Konfliktmarkierungen und Ähnlichem. Anschließend wird ein Diff zwischen diesem temporären Baum und dem tatsächlichen Merge-Commit angezeigt.

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

--combined-all-paths

Bewirkt, dass kombinierte Diffs (verwendet für Merge-Commits) den Dateinamen von allen Elternteilen auflisten. Dies hat nur dann einen Effekt, wenn --diff-merges=[dense-]combined verwendet wird, und ist wahrscheinlich nur nützlich, wenn Dateinamenä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 Raw-Diff-Format an. Siehe den Abschnitt "RAW OUTPUT FORMAT" von git-diff[1]. Dies unterscheidet sich von der Anzeige des Logs selbst im Raw-Format, 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 ein Diffstat. Standardmäßig wird so viel Platz wie nötig für den Dateinamen-Teil verwendet, und der Rest für den Grafikteil. 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 Dateinamen-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 Grafik-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 wirkt sich auf alle Befehle aus, die eine Stat-Grafik 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 beschränken, 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 NUL-Zeichen statt mit Zeilenumbrüchen.

Auch wenn --raw oder --numstat angegeben wurde, werden Pfadnamen nicht verändert und NUL-Zeichen als Ausgabefeldtrenner 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>]

Legt fest, wie Unterschiede in Submodulen angezeigt werden. Wenn --submodule=short angegeben wird, wird das short-Format 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 log-Format verwendet. Dieses Format listet die Commits im Bereich auf, wie git-submodule summary von git-submodule[1]. Wenn --submodule=diff angegeben wird, wird das diff-Format verwendet. Dieses Format zeigt einen Inline-Diff der Änderungen im Submodulinhalt zwischen dem Commit-Bereich an. Standardmäßig wird diff.submodule oder das short-Format 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 Durchsicht der Historie zu verfolgen, siehe --follow. Wenn <n> angegeben ist, ist dies ein Schwellenwert für den Ähnlichkeitsindex (d.h. die Menge der Hinzufügungen/Löschungen im Vergleich zur Dateigröße). Zum Beispiel bedeutet -M90%, dass Git ein Lösch-/Hinzufügungspaar als Umbenennung betrachten soll, wenn mehr als 90% der Datei unverändert geblieben sind. Ohne ein '%' -Zeichen wird die Zahl als Bruch mit einem Dezimalpunkt davor gelesen. D.h., -M5 wird zu 0.5 und ist somit dasselbe wie -M50%. Ebenso ist -M05 dasselbe wie -M5%. Um die Erkennung auf exakte Umbenennungen zu beschränken, verwenden Sie -M100%. Der Standard-Ähnlichkeitsindex ist 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 geändert, wenn es entweder nicht verfolgte oder geänderte Dateien enthält oder sein HEAD vom im Superprojekt aufgezeichneten Commit abweicht, und kann verwendet werden, um alle 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 nicht verfolgten Inhalt enthalten (aber sie werden immer noch auf geänderten Inhalt gescannt). Die Verwendung von dirty ignoriert alle Änderungen am Arbeitsbaum von Submodulen, nur Änderungen an den im Superprojekt gespeicherten Commits werden angezeigt (dies war das Verhalten bis 1.7.0). Die Verwendung von all verbirgt alle Änderungen an Submodulen.

--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=<depth>

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 show v1.0.0: Zeigt das Tag v1.0.0 zusammen mit dem Objekt an, auf das das Tag zeigt.
git show v1.0.0^{tree}: Zeigt den Baum an, auf den das Tag v1.0.0 verweist.
git show -s --format=%s v1.0.0^{commit}: Zeigt den Betreff des Commits an, auf den das Tag v1.0.0 verweist.
git show next~10:Documentation/README: Zeigt den Inhalt der Datei Documentation/README an, wie er im 10. letzten Commit des Branches next aktuell war.
git show master:Makefile master:t/Makefile: Verkettet den Inhalt der genannten Makefiles im Kopf des Branches master.

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.

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