English ▾ Themen ▾ Neueste Version ▾ git-diff-pairs zuletzt aktualisiert in 2.52.0

NAME

git-diff-pairs - Vergleicht den Inhalt und den Modus der bereitgestellten Blob-Paare

SYNOPSIS

git diff-pairs -z [<diff-options>]

BESCHREIBUNG

Zeigt Änderungen für Dateipaare an, die über stdin bereitgestellt werden. Die Eingabe für diesen Befehl muss im NUL-terminierten Rohausgabeformat vorliegen, wie es von Befehlen wie git diff-tree -z -r --raw generiert wird. Standardmäßig werden die ausgegebenen Diffs berechnet und im Patch-Format angezeigt, wenn stdin geschlossen wird.

Ein einzelnes NUL-Byte kann zwischen den Rohinput-Zeilen in stdin geschrieben werden, um Dateipaar-Diffs bis zu diesem Punkt zu berechnen, anstatt auf das Schließen von stdin zu warten. Ein NUL-Byte wird auch in die Ausgabe geschrieben, um zwischen diesen Diff-Batches zu trennen.

Die Verwendung dieses Befehls ermöglicht es, die traditionelle Diff-Pipeline in separate Phasen aufzubrechen, wobei diff-pairs als Ausgabephase dient. Andere Befehle, wie z.B. diff-tree, können als Frontend dienen, um das als Eingabe verwendete Roh-Diff-Format zu berechnen.

Anstatt Diffs in einem Schritt über git diff-tree -p -M zu berechnen, kann diff-tree die Dateipaare und Umbenennungsinformationen ohne die Blob-Diffs berechnen. Diese Ausgabe kann an diff-pairs übergeben werden, um die zugrunde liegenden Blob-Diffs zu generieren, wie im folgenden Beispiel gezeigt.

git diff-tree -z -r -M $a $b |
git diff-pairs -z

Die Vorausberechnung des Tree-Diffs mit Umbenennungsinformationen ermöglicht es, dass Patch-Ausgaben von diff-pairs über potenziell mehrere Aufrufe hinweg schrittweise berechnet werden können.

Pfadspezifikationen werden derzeit nicht von diff-pairs unterstützt. Die Pfadspezifikationsbeschränkung sollte vom Upstream-Befehl durchgeführt werden, der die als Eingabe verwendeten Roh-Diffs generiert.

Tree-Objekte werden derzeit nicht als Eingabe unterstützt und werden abgelehnt.

Abgekürzte Objekt-IDs in der diff-pairs-Eingabe werden nicht unterstützt. Ausgegebene Objekt-IDs können mit der Option --abbrev abgekürzt werden.

OPTIONEN

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

-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

Generiert den Diff im Rohformat. Dies ist die Standardeinstellung.

--patch-with-raw

Synonym für -p --raw.

--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 einen Diffstat. Standardmäßig wird für den Dateinamens-Teil so viel Platz wie nötig verwendet, und der Rest für den Grafikteil. Die maximale Breite entspricht standardmäßig der Terminalbreite oder 80 Spalten, wenn keine Verbindung zu einem Terminal besteht, und kann durch <width> überschrieben werden. Die Breite des Dateinamens-Teils kann durch Angabe einer weiteren Breite <name-width> nach einem Komma oder durch Setzen von diff.statNameWidth=<name-width> begrenzt werden. Die Breite des 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 einen Stat-Graphen generieren, während das Setzen von diff.statNameWidth oder diff.statGraphWidth git format-patch nicht beeinflusst. Durch Angabe eines dritten Parameters <count> können Sie die Ausgabe auf die ersten <count> Zeilen begrenzen, gefolgt von ..., falls 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

Wenn --raw, --numstat, --name-only oder --name-status angegeben wurde, werden Pfadnamen nicht verunstaltet und NUL-Zeichen als Feldtrenner verwendet.

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

--name-only

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

--name-status

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

--submodule[=<format>]

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

--color[=<when>]

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

--no-color

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

--color-moved[=<mode>]

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

no

Verschobene Zeilen werden nicht hervorgehoben.

default

Ist ein Synonym für zebra. Dies kann sich in Zukunft zu einem sinnvollere Modus ändern.

plain

Jede Zeile, die an einer Stelle hinzugefügt und an einer anderen Stelle entfernt wurde, wird mit color.diff.newMoved gefärbt. Ebenso wird color.diff.oldMoved für entfernte Zeilen verwendet, die an anderer Stelle im Diff hinzugefügt wurden. Dieser Modus erkennt jede verschobene Zeile, ist aber bei der Überprüfung nicht sehr nützlich, um festzustellen, ob ein Codeblock ohne Permutation verschoben wurde.

blocks

Blöcke von verschobenem Text von mindestens 20 alphanumerischen Zeichen werden gierig erkannt. Die erkannten Blöcke werden mit der Farbe color.diff.(old|new)Moved gefärbt. Benachbarte Blöcke können nicht voneinander unterschieden werden.

zebra

Blöcke von verschobenem Text werden wie im Modus blocks erkannt. Die Blöcke werden entweder mit der Farbe color.diff.(old|new)Moved oder color.diff.(old|new)MovedAlternative gefärbt. Der Wechsel zwischen den beiden Farben zeigt an, dass ein neuer Block erkannt wurde.

dimmed-zebra

Ähnlich wie zebra, aber es wird eine zusätzliche Dämpfung uninteressanter Teile von verschobenem Code durchgeführt. Die Randlinien zweier benachbarter Blöcke gelten als interessant, der Rest als uninteressant. dimmed_zebra ist ein veraltetes Synonym.

--no-color-moved

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

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

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

no

Ignoriert keine Leerzeichen bei der Verschiebungserkennung.

ignore-space-at-eol

Ignoriert Änderungen an Leerzeichen am Zeilenende.

ignore-space-change

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

ignore-all-space

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

allow-indentation-change

Ignoriert zunächst jegliche Leerzeichen bei der Verschiebungserkennung, gruppiert dann die verschobenen Codeblöcke nur dann zu einem Block, wenn die Änderung der Leerzeichen pro Zeile gleich ist. Dies ist mit den anderen Modi nicht kompatibel.

--no-color-moved-ws

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

--word-diff[=<mode>]

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

color

Hebt geänderte Wörter nur mit Farben hervor. Beinhaltet --color.

plain

Zeigt Wörter als [-entfernt-] und {hinzugefügt}. Versucht nicht, die Begrenzer zu escapen, falls sie im Eingabetext vorkommen, daher kann die Ausgabe mehrdeutig sein.

porcelain

Verwendet ein spezielles zeilenbasiertes Format, das für die Skriptverarbeitung bestimmt ist. Hinzugefügte/entfernte/unveränderte Laufwerke werden im üblichen einheitlichen Diff-Format ausgegeben, beginnend mit einem +/-/` ` Zeichen am Anfang der Zeile und sich bis zum Ende der Zeile erstreckend. Zeilenumbrüche im Eingabetext werden durch eine Tilde ~ auf einer eigenen Zeile dargestellt.

none

Deaktiviert die Wort-Diff-Funktion erneut.

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

--word-diff-regex=<regex>

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

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

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

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

--color-words[=<regex>]

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

--no-renames

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

--rename-empty
--no-rename-empty

Ob leere Blobs als Umbenennungsquelle verwendet werden sollen.

--check

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

--ws-error-highlight=<kind>

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

--full-index

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

--binary

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

--abbrev[=<n>]

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

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

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

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

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

-M[<n>]
--find-renames[=<n>]

Erkennt Umbenennungen. Wenn <n> angegeben ist, ist es ein Schwellenwert für den Ähnlichkeitsindex (d.h. die Menge an Hinzufügungen/Löschungen im Verhältnis zur Dateigröße). Zum Beispiel bedeutet -M90%, dass Git ein Lösch-/Hinzufügepaar als Umbenennung betrachten sollte, 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]).

--exit-code

Lässt das Programm mit Codes ähnlich wie diff(1) beenden. Das heißt, es beendet sich mit 1, wenn es Unterschiede gab, und 0 bedeutet keine Unterschiede.

--quiet

Schaltet die gesamte Ausgabe des Programms ab. Impliziert --exit-code. Deaktiviert die Ausführung externer Diff-Helfer, deren Exit-Code nicht vertrauenswürdig ist, d.h. ihre jeweilige Konfigurationsoption diff.trustExitCode oder diff.<driver>.trustExitCode oder die Umgebungsvariable GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE ist false.

--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 die Standardeinstellung. Die Verwendung von none betrachtet das Submodul als modifiziert, wenn es entweder ungetrackte oder geänderte Dateien enthält oder sein HEAD vom im Superprojekt aufgezeichneten Commit abweicht, und kann verwendet werden, um jede Einstellung der Option ignore in git-config[1] oder gitmodules[5] zu überschreiben. Wenn untracked verwendet wird, werden Submodule nicht als "dirty" betrachtet, wenn sie nur ungetrackten Inhalt enthalten (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

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

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

  3. Pfadnamen mit "ungewöhnlichen" Zeichen werden wie für die Konfigurationsvariable core.quotePath erklärt zitiert (siehe git-config[1]).

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

  5. 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);

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

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

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

  4. 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").

GIT

Teil der git[1] Suite