git-show – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

git-show – Verschiedene Arten von Objekten anzeigen

ZUSAMMENFASSUNG

git erklären [Optionen] ...

BESCHREIBUNG

Zeigt ein oder mehrere Objekte (Blobs, Bäume, Tags und Commits).

Für Commits werden die Protokollmeldung und der Textunterschied angezeigt. Außerdem wird das Merge-Commit vorgestellt
in einem speziellen Format wie produziert von git Diff-Baum --cc.

Bei Tags werden die Tag-Nachricht und die referenzierten Objekte angezeigt.

Bei Bäumen werden die Namen angezeigt (entspricht git ls-Baum mit --name-only).

Bei einfachen Blobs wird der einfache Inhalt angezeigt.

Der Befehl akzeptiert Optionen, die für den gelten git Diff-Baum Befehl, um zu steuern, wie die
Änderungen, die das Commit einführt, werden angezeigt.

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

OPTIONAL

...
Die Namen der anzuzeigenden Objekte. Eine vollständigere Liste der Möglichkeiten zur Schreibweise von Objektnamen finden Sie hier:
siehe Abschnitt „ANGEGEBENE REVISIONEN“ in gitrevisionen(7).

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

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

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

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

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

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

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

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

--notes[= ]
Zeigen Sie die Notizen an (siehe Git-Notizen(1)), die den Commit mit Anmerkungen versehen, wenn der Commit angezeigt wird
Protokollnachricht. Dies ist die Standardeinstellung für die Befehle git log, git show und git whatchanged
wenn in der Befehlszeile keine Option --pretty, --format oder --oneline angegeben ist.

Standardmäßig stammen die angezeigten Notizen aus den im aufgeführten Notizreferenzen core.notesRef und
Notes.displayRef Variablen (oder entsprechende Umgebungsüberschreibungen). Sehen git-config(1)
für weitere Informationen an.

Mit optionalem Argument, zeigen Sie diese Notizenreferenz anstelle der Standardnotizen an
Ref(s). Die Referenz gibt den vollständigen Referenznamen an, wenn sie mit refs/notes/ beginnt; wenn es
beginnt mit „notes/“, „refs/“ und andernfalls wird „refs/notes/“ vorangestellt, um einen vollständigen Namen von zu bilden
der Schiedsrichter.

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

--no-notes
Notizen nicht anzeigen. Dadurch wird die obige Option --notes negiert, indem die Liste zurückgesetzt wird
Notizen-Referenzen, aus denen Notizen angezeigt werden. Optionen werden in der auf der angegebenen Reihenfolge analysiert
Befehlszeile, also wird z. B. „--notes --notes=foo --no-notes --notes=bar“ nur angezeigt
Notizen aus „refs/notes/bar“.

--show-notes[= ], --[no-]standard-notes
Diese Optionen sind veraltet. Verwenden Sie stattdessen die oben genannten Optionen --notes/--no-notes.

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

PRETTY FORMATEN

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

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

· eine Linie



Dieser ist so kompakt wie möglich konzipiert.

· kurz

begehen
Autor:



· mittlere

begehen
Autor:
Datum:





· voller

begehen
Autor:
Begehen:





· voller

begehen
Autor:
AutorDatum:
Begehen:
CommitDate:





· E-Mail

Aus
Aus:
Datum:
Betreff: [PATCH]



· roh

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

· Format:

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

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

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

Die Platzhalter sind:

· %H: Hash festschreiben

· %h: abgekürzter Commit-Hash

· %T: Baum-Hash

· %t: abgekürzter Baum-Hash

· %P: Eltern-Hashes

· %p: abgekürzte Eltern-Hashes

· %ein: Autorenname

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

· %ae: E-Mail des Autors

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

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

· %Anzeige: Autordatum, RFC2822-Stil

· %ar: Autorendatum, relativ

· %bei: Autorendatum, UNIX-Zeitstempel

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

· %aI: Autordatum, striktes ISO 8601-Format

· %cn: Name des Committers

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

· %ce: E-Mail des Committers

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

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

· %CD: Committer-Datum, RFC2822-Stil

· %cr: Committer-Datum, relativ

· %ct: Committer-Datum, UNIX-Zeitstempel

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

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

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

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

· %e: Kodierung

· %s: Thema

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

· %b: Körper

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

· %N: Notizen festschreiben

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

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

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

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

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

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

· %gn: Reflog-Identitätsname

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

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

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

· %gs: Reflog-Betreff

· %Cred: Farbe auf Rot umstellen

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

· %Cblau: Farbe auf Blau umstellen

· %Creset: Farbe zurücksetzen

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

· %m: links, rechts oder Grenzmarkierung

· %n: Neue Zeile

· %%: ein rohes %

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

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

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

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

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

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

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

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

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

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

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

· Format:

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

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

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

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

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

COMMON DIFF OPTIONAL

-p, -u, --patch
Patch generieren (siehe Abschnitt zum Generieren von Patches).

-s, --no-patch
Diff-Ausgabe unterdrücken. Nützlich für Befehle wie git show, die den Patch anzeigen
Standardeinstellung oder um die Wirkung von --patch aufzuheben.

-U , --unified=
Unterschiede generieren mit statt der üblichen drei Kontextzeilen. Impliziert -p.

--roh
Zeigen Sie für jedes Commit eine Zusammenfassung der Änderungen im Rohformat Diff an. Siehe „RAW
Abschnitt „Ausgabeformat“ von git-diff(1). Dies unterscheidet sich von der Anzeige des Protokolls selbst
im Rohformat, was Sie mit --format=raw erreichen können.

--patch-with-raw
Synonym für -p --raw.

--minimal
Nehmen Sie sich mehr Zeit, um sicherzustellen, dass der kleinstmögliche Unterschied entsteht.

--Geduld
Generieren Sie einen Diff mit dem „Patience Diff“-Algorithmus.

--Histogramm
Generieren Sie einen Diff mit dem „Histogramm-Diff“-Algorithmus.

--diff-algorithm={patience|minimal|histogram|myers}
Wählen Sie einen Diff-Algorithmus. Die Varianten sind wie folgt:

Standard, Myers
Der grundlegende Greedy-Diff-Algorithmus. Derzeit ist dies die Standardeinstellung.

minimal
Nehmen Sie sich mehr Zeit, um sicherzustellen, dass der kleinstmögliche Unterschied entsteht.

Geduld
Verwenden Sie beim Generieren von Patches den „Patience Diff“-Algorithmus.

Histogramm
Dieser Algorithmus erweitert den Geduldsalgorithmus, um „gemeinsames Auftreten mit geringem Vorkommen“ zu unterstützen
Elemente".

Wenn Sie beispielsweise die Variable diff.algorithm auf einen nicht standardmäßigen Wert konfiguriert haben und
Wenn Sie die Standardeinstellung verwenden möchten, müssen Sie die Option --diff-algorithm=default verwenden.

--stat[= [, [, ]]]
Generieren Sie einen Diffstat. Standardmäßig wird so viel Platz wie nötig für verwendet
Dateinamenteil und der Rest für den Diagrammteil. Die maximale Breite ist standardmäßig auf Terminal eingestellt
Breite oder 80 Spalten, wenn keine Verbindung zu einem Terminal besteht, und kann durch überschrieben werden .
Die Breite des Dateinamensteils kann durch Angabe einer anderen Breite begrenzt werden
nach einem Komma. Die Breite des Diagrammteils kann mit begrenzt werden
--stat-graph-width= (betrifft alle Befehle, die ein Statistikdiagramm generieren) oder von
Einstellung von diff.statGraphWidth= (hat keinen Einfluss auf den Git-Format-Patch). Indem Sie a
dritter Parameter können Sie die Ausgabe auf die erste beschränken Zeilen, gefolgt
von ... wenn es noch mehr gibt.

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

--numstat
Ähnlich wie --stat, zeigt jedoch die Anzahl der hinzugefügten und gelöschten Zeilen in Dezimalschreibweise an
Pfadname ohne Abkürzung, um ihn maschinenfreundlicher zu machen. Für Binärdateien:
gibt zwei aus - statt 0 0 zu sagen.

--shortstat
Geben Sie nur die letzte Zeile des Formats --stat aus, die die Gesamtzahl der Änderungen enthält
Dateien sowie Anzahl der hinzugefügten und gelöschten Zeilen.

--dirstat[= ]
Geben Sie die Verteilung der relativen Änderungsmenge für jedes Unterverzeichnis aus. Der
Das Verhalten von --dirstat kann angepasst werden, indem eine durch Kommas getrennte Liste übergeben wird
Parameter. Die Standardeinstellungen werden durch die Konfigurationsvariable diff.dirstat gesteuert
(sehen git-config(1)). Folgende Parameter stehen zur Verfügung:

Änderungen
Berechnen Sie die Dirstat-Nummern, indem Sie die Zeilen zählen, die aus dem entfernt wurden
Quelle hinzugefügt oder zum Ziel hinzugefügt werden. Dabei wird die Menge an reinem Code ignoriert
Bewegungen innerhalb einer Datei. Mit anderen Worten: Das Neuanordnen von Zeilen in einer Datei ist nicht möglich
genauso viel gezählt wie andere Änderungen. Dies ist das Standardverhalten, wenn kein Parameter vorhanden ist
gegeben ist.

Linien
Berechnen Sie die Dirstat-Zahlen, indem Sie die reguläre zeilenbasierte Diff-Analyse durchführen, und
Summieren der Anzahl der entfernten/hinzugefügten Zeilen. (Zählen Sie bei Binärdateien 64-Byte-Blöcke
stattdessen, da Binärdateien kein natürliches Konzept von Zeilen haben). Das ist ein Mehr
teurer --dirstat-Verhalten als das Änderungsverhalten, aber es zählt
neu angeordnete Zeilen innerhalb einer Datei ebenso wie andere Änderungen. Die resultierende Ausgabe ist
im Einklang mit dem, was Sie von den anderen --*stat-Optionen erhalten.

Dateien
Berechnen Sie die Dirstat-Nummern, indem Sie die Anzahl der geänderten Dateien zählen. Jeder hat sich verändert
Datei zählt in der Dirstat-Analyse gleichermaßen. Dies ist rechnerisch am günstigsten
--dirstat Verhalten, da der Dateiinhalt überhaupt nicht geprüft werden muss.

kumulativ
Zählen Sie Änderungen in einem untergeordneten Verzeichnis auch für das übergeordnete Verzeichnis. Beachten Sie, dass
Bei kumulierter Verwendung kann die Summe der gemeldeten Prozentsätze 100 % überschreiten. Der
Das Standardverhalten (nicht kumulativ) kann mit der Funktion „Nicht kumulativ“ angegeben werden
Parameters.


Ein ganzzahliger Parameter gibt einen Cut-off-Prozentsatz an (standardmäßig 3 %). Verzeichnisse
Beiträge, die weniger als diesen Prozentsatz zu den Änderungen beitragen, werden in der Ausgabe nicht angezeigt.

Beispiel: Im Folgenden werden geänderte Dateien gezählt, während Verzeichnisse mit weniger Dateien ignoriert werden
mehr als 10 % der Gesamtmenge der geänderten Dateien ausmachen und die Anzahl der untergeordneten Verzeichnisse ansammelt
in den übergeordneten Verzeichnissen: --dirstat=files,10,cumulative.

--Zusammenfassung
Geben Sie eine komprimierte Zusammenfassung erweiterter Header-Informationen wie Erstellungen und Umbenennungen aus
und Modusänderungen.

--patch-with-stat
Synonym für -p --stat.

-z
Trennen Sie die Commits durch NULs statt durch neue Zeilenumbrüche.

Wenn --raw oder --numstat angegeben wurde, munge außerdem keine Pfadnamen und verwende NULs als
Abschlusszeichen für Ausgabefelder.

Ohne diese Option enthält jede Pfadnamenausgabe TAB, LF, doppelte Anführungszeichen und
Backslash-Zeichen werden durch \t, \n, \" bzw. \\ und den Pfadnamen ersetzt
wird in doppelte Anführungszeichen gesetzt, wenn eine dieser Ersetzungen erfolgt ist.

--nur Name
Nur Namen geänderter Dateien anzeigen.

--Name-Status
Zeigt nur Namen und Status der geänderten Dateien an. Siehe die Beschreibung des --diff-filters
Option zur Bedeutung der Statusbuchstaben.

--submodule[= ]
Geben Sie an, wie Unterschiede in Submodulen angezeigt werden. Wenn --submodule oder --submodule=log
gegeben ist, die Log Format verwendet wird. Dieses Format listet die Commits im Bereich wie auf Git-
Untermodul(1) Zusammenfassung tut es. Weglassen der Option --submodule oder Angabe
--submodule=short, verwendet die kurz Format. Dieses Format zeigt nur die Namen der
Commits am Anfang und Ende des Bereichs. Kann über das diff.submodul angepasst werden
variable Konfiguration.

--color[= ]
Farbunterschied anzeigen. --color (also ohne =) ist dasselbe wie --color=always.
kann immer, nie oder automatisch sein.

--keine Farbe
Schalten Sie den Farbunterschied aus. Es ist dasselbe wie --color=never.

--word-diff[= ]
Zeigen Sie einen Wortunterschied mit dem an um geänderte Wörter abzugrenzen. Standardmäßig sind es Wörter
durch Leerzeichen getrennt; siehe --word-diff-regex unten. Der Standardmäßig ist Ebene,
und muss einer von Folgendem sein:

Farbe
Markieren Sie geänderte Wörter nur mit Farben. Impliziert --color.

Ebene
Wörter als [-removed-] und {+added+} anzeigen. Unternimmt keine Fluchtversuche
Trennzeichen, wenn sie in der Eingabe erscheinen, sodass die Ausgabe möglicherweise mehrdeutig ist.

Porzellan
Verwenden Sie ein spezielles zeilenbasiertes Format, das für den Skriptverbrauch bestimmt ist.
Hinzugefügte/entfernte/unveränderte Läufe werden im üblichen einheitlichen Diff-Format gedruckt.
beginnend mit einem +/-/` `-Zeichen am Anfang der Zeile und endend auf
das Ende der Linie. Zeilenumbrüche in der Eingabe werden durch eine Tilde ~ in einer Zeile dargestellt
seiner eigenen.

keine
Deaktivieren Sie die Wortdifferenz erneut.

Beachten Sie, dass trotz des Namens des ersten Modus die Farbe zur Hervorhebung der Änderungen verwendet wird
Teile in allen Modi, sofern aktiviert.

--word-diff-regex=
Verwenden um zu entscheiden, was ein Wort ist, anstatt Reihen von Nicht-Leerzeichen zu berücksichtigen
ein Wort sein. Impliziert auch --word-diff, sofern es nicht bereits aktiviert war.

Jede nicht überlappende Übereinstimmung der gilt als Wort. Alles dazwischen
Diese Übereinstimmungen werden als Leerzeichen betrachtet und zum Zwecke der Suche ignoriert(!).
Unterschiede. Möglicherweise möchten Sie |[^[:space:]] an Ihren zu erstellenden regulären Ausdruck anhängen
Stellen Sie sicher, dass alle Zeichen, die keine Leerzeichen sind, übereinstimmen. Eine Übereinstimmung, die eine neue Zeile enthält, ist
am Zeilenumbruch stillschweigend abgeschnitten(!).

Beispiel: --word-diff-regex=. behandelt jedes Zeichen als Wort und
Zeigen Sie dementsprechend Unterschiede Zeichen für Zeichen an.

Der reguläre Ausdruck kann auch über einen Diff-Treiber oder eine Konfigurationsoption festgelegt werden, siehe
gittributes(1) oder git-config(1). Die explizite Angabe überschreibt alle Diff-Treiber oder
Konfigurationseinstellung. Diff-Treiber überschreiben Konfigurationseinstellungen.

--color-words[= ]
Entspricht --word-diff=color plus (wenn ein regulärer Ausdruck angegeben wurde)
--word-diff-regex= .

--no-renames
Deaktivieren Sie die Umbenennungserkennung, auch wenn die Konfigurationsdatei dies standardmäßig vorgibt
so.

--prüfen
Warnen Sie, wenn Änderungen zu Leerzeichenfehlern führen. Was als Leerzeichenfehler gilt, ist
gesteuert durch die core.whitespace-Konfiguration. Standardmäßig werden nachgestellte Leerzeichen verwendet
(einschließlich Zeilen, die ausschließlich aus Leerzeichen bestehen) und einem Leerzeichen
Unmittelbar gefolgt von einem Tabulatorzeichen innerhalb des ersten Einzugs der Zeile sind
werden als Leerzeichenfehler betrachtet. Wird mit einem Status ungleich Null beendet, wenn Probleme gefunden werden. Nicht
kompatibel mit --exit-code.

--ws-error-highlight=
Heben Sie Leerraumfehler in den von angegebenen Zeilen hervor in der von Ihnen angegebenen Farbe
color.diff.whitespace. ist eine durch Kommas getrennte Liste des alten, neuen Kontexts. Wenn
Diese Option ist nicht verfügbar, nur Leerzeichenfehler in neuen Zeilen werden hervorgehoben. Z.B
--ws-error-highlight=new,old hebt Leerzeichenfehler sowohl beim Löschen als auch beim Hinzufügen hervor
Linien. Alle können als Abkürzung für alt, neu, Kontext verwendet werden.

--full-index
Zeigen Sie statt der ersten Handvoll Zeichen den vollständigen Blob vor und nach dem Bild an
Objektnamen in der „Index“-Zeile beim Generieren der Patch-Format-Ausgabe.

--binär
Geben Sie zusätzlich zu --full-index ein binäres Diff aus, das mit git-apply angewendet werden kann.

--Abkürzung[= ]
Anstatt den vollständigen 40-Byte-Hexadezimal-Objektnamen in der Ausgabe im Diff-Raw-Format anzuzeigen
und Diff-Tree-Kopfzeilen zeigen nur einen Teil des Präfixes. Dies ist unabhängig von der
--full-index-Option oben, die das Diff-Patch-Ausgabeformat steuert. Nicht standardmäßig
Anzahl der Ziffern kann mit --abbrev= angegeben werden .

-B[ ][/ ], --break-rewrites[=[ ][/ ]]
Unterteilen Sie die Änderungen des vollständigen Umschreibens in Lösch- und Erstellungspaare. Dies dient zwei
Zwecke:

Es wirkt sich auf die Art und Weise einer Änderung aus, die einem vollständigen Neuschreiben einer Datei und nicht einer Serie gleichkommt
aus Löschungen und Einfügungen vermischt mit sehr wenigen Zeilen, die zufällig übereinstimmen
textlich als Kontext, sondern als einzelne Löschung von allem Alten, gefolgt von einem
einmalige Einfügung von allem Neuen, und die Zahl m steuert diesen Aspekt des -B
Option (standardmäßig 60 %). -B/70 % gibt an, dass weniger als 30 % des Originals vorhanden sein sollen
Bleiben Sie im Ergebnis, damit Git es als eine vollständige Neufassung betrachten kann (d. h. andernfalls die
Der resultierende Patch besteht aus einer Reihe von Lösch- und Einfügungsvorgängen, gemischt mit dem Kontext
Linien).

Bei Verwendung mit -M wird eine vollständig neu geschriebene Datei auch als Quelle von a betrachtet
umbenennen (normalerweise berücksichtigt -M nur eine Datei, die verschwunden ist, als Quelle einer Umbenennung),
und die Zahl n steuert diesen Aspekt der Option -B (standardmäßig 50 %). -B20%
Gibt an, dass eine Änderung mit Hinzufügung und Löschung im Vergleich zu 20 % oder mehr der
Dateigröße kommen als mögliche Quelle für eine Umbenennung in Frage
eine andere Datei.

-M[ ], --find-renames[= ]
Wenn Sie Diffs generieren, erkennen und melden Sie Umbenennungen für jeden Commit. Für folgende Dateien
across Umbenennungen beim Durchlaufen des Verlaufs, siehe --follow. Wenn n angegeben ist, ist es a
Schwellenwert für den Ähnlichkeitsindex (d. h. Anzahl der Hinzufügungen/Löschungen im Vergleich zum
Dateigröße). -M90% bedeutet beispielsweise, dass Git ein Lösch-/Hinzufügen-Paar als a betrachten sollte
Umbenennen, wenn mehr als 90 % der Datei nicht geändert wurden. Ohne ein %-Zeichen lautet die Zahl „to“.
als Bruch gelesen werden, mit einem Dezimalpunkt davor. Dh, -M5 wird 0.5 und beträgt
also dasselbe wie -M50%. Ebenso ist -M05 dasselbe wie -M5%. Um die Erkennung zu beschränken
Für genaue Umbenennungen verwenden Sie -M100%. Der Standard-Ähnlichkeitsindex beträgt 50 %.

-C[ ], --find-copies[= ]
Erkennen Sie Kopien und Umbenennungen. Siehe auch --find-copies-harder. Wenn n angegeben ist, ist es
hat die gleiche Bedeutung wie für -M .

--find-copys-harder
Aus Leistungsgründen findet die Option -C standardmäßig nur Kopien der Originaldatei
der Kopie wurde im selben Änderungssatz geändert. Dieses Flag veranlasst den Befehl zur Überprüfung
unveränderte Dateien als Kandidaten für die Kopierquelle. Das ist sehr teuer
Betrieb für große Projekte, also verwenden Sie es mit Vorsicht. Geben Sie mehr als eine -C-Option an
hat den gleichen Effekt.

-D, --irreversible-delete
Lassen Sie das Vorbild für Löschvorgänge weg, dh drucken Sie nur den Header, nicht jedoch den Unterschied zwischen den
preimage und /dev/null. Der resultierende Patch ist nicht dazu gedacht, mit Patch oder angewendet zu werden
git apply; Dies ist ausschließlich für Leute gedacht, die sich nur auf die Überprüfung konzentrieren möchten
Text nach der Änderung. Darüber hinaus fehlen der Ausgabe offensichtlich genügend Informationen
Wenden Sie einen solchen Patch in umgekehrter Reihenfolge an, auch manuell, daher der Name der Option.

Wenn Sie es zusammen mit -B verwenden, lassen Sie auch das Vorbild im Löschteil von a weg
Paar löschen/erstellen.

-l
Die Optionen -M und -C erfordern eine Verarbeitungszeit von O(n^2), wobei n die Anzahl von ist
potenzielle Ziele umbenennen/kopieren. Diese Option verhindert, dass die Umbenennungs-/Kopiererkennung ausgeführt wird
wenn die Anzahl der Umbenennungs-/Kopierziele die angegebene Anzahl überschreitet.

--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) oder umbenannt sind
(R), deren Typ (z. B. reguläre Datei, Symlink, Submodul, ...) geändert wurde (T), sind
Nicht zusammengeführt (U), unbekannt (X) oder deren Paarung unterbrochen (B). Jede Kombination
Es können maximal XNUMX der Filterzeichen (einschließlich keines) verwendet werden. Wenn * (Alles oder nichts) hinzugefügt wird
Für die Kombination werden alle Pfade ausgewählt, wenn es eine Datei gibt, die mit anderen übereinstimmt
Kriterien im Vergleich; Wenn es keine Datei gibt, die anderen Kriterien entspricht, passiert nichts
ist ausgewählt.

-S
Suchen Sie nach Unterschieden, die die Häufigkeit des Vorkommens der angegebenen Zeichenfolge ändern
(z. B. Hinzufügen/Löschen) in einer Datei. Für den Gebrauch durch den Skripter gedacht.

Dies ist nützlich, wenn Sie nach einem genauen Codeblock (z. B. einer Struktur) suchen und möchten
Um die Geschichte dieses Blocks seit seiner Entstehung zu erfahren: Verwenden Sie die Funktion
iterativ, um den interessanten Block im Vorbild wieder in -S einzuspeisen und weiterzumachen
bis Sie die allererste Version des Blocks erhalten.

-G
Suchen Sie nach Unterschieden, deren Patchtext übereinstimmende hinzugefügte/entfernte Zeilen enthält .

Um den Unterschied zwischen -S zu veranschaulichen --pickaxe-regex und -G , halten
ein Commit mit dem folgenden Unterschied in derselben Datei:

+ return !regexec(regexp, two->ptr, 1, ®match, 0);
...
- hit = !regexec(regexp, mf2.ptr, 1, ®match, 0);

Während git log -G"regexec\(regexp" dieses Commit anzeigt, git log -S"regexec\(regexp"
--pickaxe-regex wird nicht (weil die Anzahl der Vorkommen dieser Zeichenfolge nicht stimmt).
Veränderung).

Siehe die Spitzhacke Eintritt in gitdiffcore(7) für weitere Informationen.

--pickaxe-all
Wenn -S oder -G eine Änderung findet, werden alle Änderungen in diesem Änderungssatz angezeigt, nicht nur die
Dateien, die die Änderung enthalten .

--pickaxe-regex
Behandeln Sie die wird -S als erweiterter regulärer POSIX-Ausdruck zur Übereinstimmung übergeben.

-Ö
Geben Sie den Patch in der in der angegebenen Reihenfolge aus , das eine Muschelkugel hat
Muster pro Zeile. Dies überschreibt die Konfigurationsvariable diff.orderFile (siehe Git-
Config(1)). Um diff.orderFile abzubrechen, verwenden Sie -O/dev/null.

-R
Zwei Eingänge vertauschen; Das heißt, es werden Unterschiede zwischen Index oder Datei auf der Festplatte und Baum angezeigt
Inhalt.

--relative[= ]
Wenn es aus einem Unterverzeichnis des Projekts ausgeführt wird, kann es angewiesen werden, Änderungen außerhalb auszuschließen
Mit dieser Option können Sie das Verzeichnis öffnen und die Pfadnamen relativ dazu anzeigen. Wenn Sie nicht da sind
In einem Unterverzeichnis (z. B. in einem Bare-Repository) können Sie benennen, welches Unterverzeichnis erstellt werden soll
die Ausgabe relativ zu durch Angabe von a als Argument.

-ein Text
Behandeln Sie alle Dateien als Text.

--ignore-space-at-eol
Ignorieren Sie Änderungen im Leerraum bei EOL.

-b, --ignore-space-change
Ignorieren Sie Änderungen in der Menge an Leerzeichen. Dies ignoriert Leerzeichen am Zeilenende und
betrachtet alle anderen Sequenzen aus einem oder mehreren Leerzeichen als gleichwertig.

-w, --ignore-all-space
Leerzeichen beim Zeilenvergleich ignorieren. Dadurch werden Unterschiede ignoriert, selbst wenn eine Zeile vorhanden ist
Leerzeichen, wo die andere Zeile keines hat.

--leerzeilen ignorieren
Ignorieren Sie Änderungen, deren Zeilen alle leer sind.

--inter-hunk-context=
Zeigt dabei den Kontext zwischen Diff-Hunks bis zur angegebenen Anzahl von Zeilen an
Verschmelzung von Kerlen, die nahe beieinander liegen.

-W, --function-context
Zeigen Sie die gesamten umgebenden Funktionen von Änderungen an.

--ext-diff
Ermöglicht die Ausführung eines externen Diff-Helfers. Wenn Sie einen externen Diff-Treiber mit einstellen
gittributes(5) Sie müssen diese Option mit verwenden Git-Log(1) und Freunde.

--no-ext-diff
Externe Diff-Treiber nicht zulassen.

--textconv, --no-textconv
Erlauben (oder verbieten) Sie die Ausführung externer Textkonvertierungsfilter beim Vergleich von Binärdateien
Dateien. Sehen gittributes(5) für Einzelheiten. Da es sich bei Textconv-Filtern normalerweise um a handelt
Bei der Einwegkonvertierung ist das resultierende Diff für den menschlichen Verzehr geeignet, kann es aber nicht
angewendet werden. Aus diesem Grund sind Textconv-Filter standardmäßig nur für aktiviert Git-
diff(1) und Git-Log(1), aber nicht für Git-Format-Patch(1) oder diff-Sanitärbefehle.

--ignore-submodules[= ]
Ignorieren Sie Änderungen an Submodulen in der Diff-Generierung. kann entweder „keine“ sein,
„untracked“, „dirty“ oder „all“, was die Standardeinstellung ist. Wenn Sie „none“ verwenden, wird Folgendes berücksichtigt
Submodul geändert, wenn es entweder nicht verfolgte oder geänderte Dateien oder seinen HEAD enthält
unterscheidet sich von dem im Superprojekt aufgezeichneten Commit und kann zum Überschreiben eines beliebigen verwendet werden
Einstellungen des ignorieren Option in git-config(1) oder gitmodule(5). Wenn „untracked“ ist
Verwendete Submodule gelten nicht als schmutzig, wenn sie nur nicht verfolgte Inhalte enthalten (aber
sie werden weiterhin nach geänderten Inhalten durchsucht). Bei Verwendung von „dirty“ werden alle Änderungen ignoriert
Im Arbeitsbaum der Submodule werden nur Änderungen an den Commits im Superprojekt gespeichert
angezeigt (dies war das Verhalten bis 1.7.0). Wenn Sie „all“ verwenden, werden alle Änderungen ausgeblendet
Submodule.

--src-prefix=
Zeigt das angegebene Quellpräfix anstelle von „a/“ an.

--dst-prefix=
Zeigt das angegebene Zielpräfix anstelle von „b/“ an.

--kein Präfix
Zeigt kein Quell- oder Zielpräfix an.

Eine ausführlichere Erläuterung dieser allgemeinen Optionen finden Sie auch unter gitdiffcore(7).

ERSTELLEN PATCHES MIT -P

Wenn „git-diff-index“, „git-diff-tree“ oder „git-diff-files“ mit a ausgeführt werden -p Option: „git
diff" ohne die --roh Option oder „git log“ mit der Option „-p“ erzeugen sie das nicht
Ausgabe wie oben beschrieben; Stattdessen erstellen sie eine Patch-Datei. Sie können die Erstellung anpassen
solcher Patches über die Umgebungsvariablen GIT_EXTERNAL_DIFF und GIT_DIFF_OPTS.

Was die Option -p erzeugt, unterscheidet sich geringfügig vom herkömmlichen Diff-Format:

1. Es wird ein „git diff“-Header vorangestellt, der wie folgt aussieht:

diff --git a/file1 b/file2

Die Dateinamen a/ und b/ sind identisch, es sei denn, es handelt sich um Umbenennen/Kopieren. Besonders sogar
für eine Erstellung oder Löschung ist /dev/null nicht wird anstelle von a/ oder b/ verwendet
Dateinamen.

Beim Umbenennen/Kopieren zeigen Datei1 und Datei2 den Namen der Quelldatei an
rename/copy und der Name der Datei, die rename/copy erzeugt.

2. Es folgen eine oder mehrere erweiterte Kopfzeilen:

Alter Modus
neuer Modus
Modus für gelöschte Dateien
Neuer Dateimodus
Kopie von
Kopieren nach
umbenennen von
umbenennen in
Ähnlichkeitsindex
Unähnlichkeitsindex
Index ..

Dateimodi werden als 6-stellige Oktalzahlen einschließlich Dateityp und Datei gedruckt
Berechtigungsbits.

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

Der Ähnlichkeitsindex ist der Prozentsatz unveränderter Linien und der Unähnlichkeitsindex
ist der Prozentsatz der geänderten Zeilen. Es ist eine abgerundete Ganzzahl, gefolgt von einem
Prozentzeichen. Der Ähnlichkeitsindexwert von 100 % ist somit für zwei gleiche Dateien reserviert,
während 100 % Unähnlichkeit bedeutet, dass keine Zeile aus der alten Datei in die neue übernommen wurde
eins.

Die Indexzeile enthält die SHA-1-Prüfsumme vor und nach der Änderung. Der Ist
enthalten, wenn sich der Dateimodus nicht ändert; andernfalls geben separate Zeilen das Alte an
und der neue Modus.

3. TAB-, LF-, doppelte Anführungszeichen und Backslash-Zeichen in Pfadnamen werden als \t, \n,
\" bzw. \\. Wenn eine solche Ersetzung erforderlich ist, dann das Ganze
Der Pfadname wird in doppelte Anführungszeichen gesetzt.

4. Alle Datei1-Dateien in der Ausgabe beziehen sich auf Dateien vor dem Festschreiben und alle Datei2
Dateien beziehen sich auf Dateien nach dem Commit. Es ist falsch, jede Änderung auf jede einzelne anzuwenden
Datei nacheinander ablegen. Mit diesem Patch werden beispielsweise a und b vertauscht:

diff --git a/ab/b
umbenennen von a
umbenennen in b
diff --git a/bb/a
Umbenennen von b
umbenennen in a

KOMBINIERT DIFF FORMAT

Jeder Diff-erzeugende Befehl kann die Option -c oder --cc verwenden, um einen zu erzeugen kombiniert diff wann
zeigt eine Zusammenführung. Dies ist das Standardformat beim Anzeigen von Zusammenführungen mit git-diff(1) oder Git-
erklären(1). Beachten Sie auch, dass Sie jedem dieser Befehle die Option -m geben können, um sie zu erzwingen
Generierung von Diffs mit einzelnen übergeordneten Elementen einer Zusammenführung.

A kombiniert diff Format sieht so aus:

diff --combined beschreiben.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 beschreiben(char *arg)
-static void beschreiben(struct commit *cmit, int last_one)
++static void beschreiben(char *arg, int last_one)
{
+ unsigned char sha1[20];
+ struct commit *cmit;
struct commit_list *list;
static int initialisiert = 0;
struct commit_name *n;

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

1. Es wird ein „git diff“-Header vorangestellt, der so aussieht (when -c Option ist
benutzt):

diff --combined-Datei

oder so (wann --cc Option wird verwendet):

diff --cc-Datei

2. Es folgen eine oder mehrere erweiterte Kopfzeilen (dieses Beispiel zeigt eine Zusammenführung mit
zwei Eltern):

Index , ..
Modus , ..
Neuer Dateimodus
Modus für gelöschte Dateien ,

Der Modus , .. Zeile erscheint nur, wenn mindestens eine der Ist
anders als der Rest. Erweiterte Header mit Informationen zu erkannten Inhalten
Bewegung (Umbenennen und Kopiererkennung) sind für die Arbeit mit Diff von zwei ausgelegt
und werden nicht vom kombinierten Diff-Format verwendet.

3. Es folgt ein zweizeiliger From-File/To-File-Header

--- eine Datei
+++ b/Datei

Ähnlich dem zweizeiligen Header für herkömmliche einheitlich Diff-Format, /dev/null wird verwendet
Signal erstellte oder gelöschte Dateien.

4. Das Chunk-Header-Format wurde geändert, um zu verhindern, dass Personen es versehentlich weiterleiten
Patch -p1. Das kombinierte Diff-Format wurde zur Überprüfung von Merge-Commit-Änderungen erstellt
war nicht für die Bewerbung gedacht. Die Änderung ähnelt der Änderung im erweiterten Index
Header:

@@@ @@@

Es gibt (Anzahl der Eltern + 1) @-Zeichen im Chunk-Header für kombinierte Diff
Format.

Im Gegensatz zu den traditionellen einheitlich Diff-Format, das zwei Dateien A und B mit einem einzigen zeigt
Spalte mit - (Minus – erscheint in A, wird aber in B entfernt), + (Plus – fehlt in A, fehlt aber
B hinzugefügt) oder das Präfix „ “ (Leerzeichen – unverändert), dieses Format vergleicht zwei oder mehr Dateien
Datei1, Datei2,... mit einer Datei X und zeigt, wie sich X von jeder DateiN unterscheidet. Eine Spalte
für jede DateiN wird der Ausgabezeile vorangestellt, um zu vermerken, wie sich die Zeile von X unterscheidet
es.

A - Zeichen in der Spalte N bedeutet, dass die Zeile in DateiN erscheint, aber nicht erscheint
im Ergebnis. Ein +-Zeichen in der Spalte N bedeutet, dass die Zeile im Ergebnis erscheint,
und fileN hat diese Zeile nicht (mit anderen Worten, die Zeile wurde ab dem Punkt hinzugefügt).
Ansicht dieses Elternteils).

In der obigen Beispielausgabe wurde die Funktionssignatur in beiden Dateien geändert (daher zwei).
- Entfernungen sowohl aus Datei1 als auch aus Datei2, plus ++, um zu bedeuten, dass eine hinzugefügte Zeile dies nicht tut
erscheinen entweder in Datei1 oder Datei2). Auch acht weitere Zeilen sind mit Datei1 identisch, tun es aber
erscheint nicht in Datei2 (daher mit dem Präfix +).

Wenn es von git diff-tree -c angezeigt wird, werden die übergeordneten Elemente eines Merge-Commits mit dem Merge verglichen
Ergebnis (d. h. Datei1..DateiN sind die übergeordneten Elemente). Wenn es von git diff-files -c angezeigt wird, wird es verglichen
Die beiden ungelösten übergeordneten Elemente werden mit der Arbeitsbaumdatei zusammengeführt (d. h. Datei 1 ist Stufe 2, auch bekannt als
„unsere Version“, Datei2 ist Stufe 3, auch bekannt als „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 in der aktuellen Fassung vom 10. an
Letztes Commit des Zweigs als nächstes.

git show master:Makefile master:t/Makefile
Verkettet den Inhalt dieser Makefiles im Kopf des Zweigmasters.

DISKUSSION

Git ist bis zu einem gewissen Grad zeichenkodierungsunabhängig.

· Der Inhalt der Blob-Objekte sind nicht interpretierte Bytefolgen. Es gibt kein
Kodierung der Übersetzung auf der Kernebene.

· Pfadnamen sind in UTF-8-Normalisierungsform C kodiert. Dies gilt für Baumobjekte,
die Indexdatei, Referenznamen sowie Pfadnamen in Befehlszeilenargumenten,
Umgebungsvariablen und Konfigurationsdateien (.git/config (siehe git-config(1)), ignorieren(5)
gittributes(5) und gitmodule(5)).

Beachten Sie, dass Git auf der Kernebene Pfadnamen einfach als Sequenzen von Nicht-NUL behandelt
Bytes gibt es keine Konvertierungen der Pfadnamencodierung (außer auf Mac und Windows).
Daher funktioniert die Verwendung von Nicht-ASCII-Pfadnamen meistens sogar auf Plattformen und Dateien
Systeme, die ältere erweiterte ASCII-Codierungen verwenden. Repositorys, die am . erstellt wurden
solche Systeme funktionieren auf UTF-8-basierten Systemen (zB Linux, Mac, Windows) nicht richtig
und umgekehrt. Darüber hinaus gehen viele Git-basierte Tools einfach davon aus, dass Pfadnamen
UTF-8 und zeigt andere Codierungen nicht richtig an.

· Commit-Protokollnachrichten werden normalerweise in UTF-8 kodiert, aber auch andere erweiterte ASCII-Kodierungen
werden ebenfalls unterstützt. Dazu gehören ISO-8859-x, CP125x und viele andere, aber nicht
UTF-16/32, EBCDIC und CJK Multi-Byte-Kodierungen (GBK, Shift-JIS, Big5, EUC-x, CP9xx
etc.).

Obwohl wir empfehlen, dass die Commit-Log-Meldungen in UTF-8 kodiert sind, sind sowohl der Kern als auch der
Git Porcelain wurde entwickelt, um UTF-8 für Projekte nicht zu erzwingen. Wenn alle Teilnehmer von a
bestimmte Projekte finden es bequemer, Legacy-Kodierungen zu verwenden, Git verbietet es nicht
es. Es gibt jedoch ein paar Dinge zu beachten.

1. git verpflichten und git Commit-Baum gibt eine Warnung aus, wenn die ihm übergebene Commit-Log-Meldung
sieht nicht wie eine gültige UTF-8-Zeichenfolge aus, es sei denn, Sie sagen ausdrücklich, dass Ihr Projekt a . verwendet
Legacy-Codierung. Der Weg, dies zu sagen, ist i18n.commitencoding in .git/config
Datei, wie folgt:

[i18n]
Commitencoding = ISO-8859-1

Commit-Objekte, die mit der obigen Einstellung erstellt wurden, zeichnen den Wert von i18n.commitencoding auf
in seinem Codierungsheader. Dies ist, um anderen Leuten zu helfen, die sie später ansehen. Mangel an
Dieser Header impliziert, dass die Commit-Log-Meldung in UTF-8 kodiert ist.

2. git Log, git erklären, git Schuld und Freunde schauen sich den Codierungsheader eines Commits an
-Objekt und versuchen Sie, die Protokollnachricht in UTF-8 umzucodieren, sofern nicht anders angegeben. Du
kann die gewünschte Ausgabecodierung mit i18n.logoutputencoding in .git/config festlegen
Datei, wie folgt:

[i18n]
Protokollausgabecodierung = ISO-8859-1

Wenn Sie diese Konfigurationsvariable nicht haben, ist der Wert von i18n.commitencoding
stattdessen verwendet.

Beachten Sie, dass wir uns bewusst dafür entschieden haben, die Commit-Log-Meldung nicht neu zu codieren, wenn ein Commit
gemacht, um UTF-8 auf der Ebene des Commit-Objekts zu erzwingen, da eine Umcodierung in UTF-8 nicht möglich ist
zwangsläufig ein reversibler Vorgang.

GIT

Ein Teil des git(1) Suite

Nutzen Sie git-show online über die Dienste von onworks.net