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

NAME

git-range-diff - Vergleicht zwei Commit-Bereiche (z. B. zwei Versionen eines Branches)

SYNOPSIS

git range-diff [--color=[<when>]] [--no-color] [<diff-options>]
	[--no-dual-color] [--creation-factor=<factor>]
	[--left-only | --right-only] [--diff-merges=<format>]
	[--remerge-diff]
	( <range1> <range2> | <rev1>…​<rev2> | <base> <rev1> <rev2> )
	[[--] <path>…​]

BESCHREIBUNG

Dieser Befehl zeigt die Unterschiede zwischen zwei Versionen einer Patch-Serie oder allgemeiner zwischen zwei Commit-Bereichen (wobei Merge-Commits ignoriert werden).

Im Falle von <Pfad>-Argumenten werden diese Commit-Bereiche entsprechend eingeschränkt.

Dazu werden zuerst Paare von Commits aus beiden Commit-Bereichen gefunden, die einander entsprechen. Zwei Commits gelten als entsprechend, wenn die Differenz zwischen ihren Patches (d.h. Autoreninformationen, Commit-Nachricht und Commit-Diff) im Verhältnis zur Größe der Patches als geringfügig klein erachtet wird. Einzelheiten siehe "Algorithmus" unten.

Schließlich wird die Liste der übereinstimmenden Commits in der Reihenfolge des zweiten Commit-Bereichs angezeigt, wobei nicht übereinstimmende Commits unmittelbar nach allen ihren Vorfahren eingefügt werden.

Es gibt drei Möglichkeiten, die Commit-Bereiche anzugeben:

  • <Bereich1> <Bereich2>: Jeder Commit-Bereich kann die Form <Basis>..<Rev>, <Rev>^! oder <Rev>^-<n> haben. Weitere Informationen finden Sie unter ANGABE VON BEREICHEN in gitrevisions[7].

  • <Rev1>...<Rev2>. Dies ist äquivalent zu <Rev2>..<Rev1> <Rev1>..<Rev2>.

  • <Basis> <Rev1> <Rev2>: Dies ist äquivalent zu <Basis>..<Rev1> <Basis>..<Rev2>.

OPTIONEN

--no-dual-color

Wenn sich die Commit-Diffs unterscheiden, rekonstruiert git range-diff die ursprüngliche Farbgebung der Diffs und fügt äußere -/+ Diff-Marker mit einem roten/grünen **Hintergrund** hinzu, um leichter zu erkennen, z. B. wenn sich die genauen hinzugefügten Zeilen geändert haben.

Zusätzlich werden die Commit-Diff-Zeilen, die nur im ersten Commit-Bereich vorhanden sind, "gedimmt" angezeigt (dies kann mit der Konfigurationseinstellung color.diff.<Slot> überschrieben werden, wobei <Slot> einer von contextDimmed, oldDimmed und newDimmed ist), und die Commit-Diff-Zeilen, die nur im zweiten Commit-Bereich vorhanden sind, werden fett angezeigt (was mit den Konfigurationseinstellungen color.diff.<Slot> überschrieben werden kann, wobei <Slot> einer von contextBold, oldBold oder newBold ist).

Dies ist range-diff als "Dual Coloring" bekannt. Verwenden Sie --no-dual-color, um alle Zeilen gemäß den äußeren Diff-Markern zu färben (und die innere Differenz hinsichtlich der Farbe vollständig zu ignorieren).

--creation-factor=<Prozent>

Setzt den "Fudge-Faktor" für Erstellung/Löschung auf <Prozent>. Standard ist 60. Versuchen Sie einen größeren Wert, wenn git range-diff eine große Änderung fälschlicherweise als vollständige Umschreibung (Löschung eines Commits und Hinzufügen eines anderen) betrachtet, und einen kleineren Wert im umgekehrten Fall. Siehe den Abschnitt "Algorithmus" unten für eine Erklärung, warum dies notwendig ist.

--left-only

Unterdrückt Commits, die im ersten angegebenen Bereich (oder im "linken Bereich" bei Verwendung des Formats <Rev1>...<Rev2>) fehlen.

--right-only

Unterdrückt Commits, die im zweiten angegebenen Bereich (oder im "rechten Bereich" bei Verwendung des Formats <Rev1>...<Rev2>) fehlen.

--diff-merges=<Format>

Anstatt Merge-Commits zu ignorieren, werden für diese Diffs unter Verwendung der entsprechenden --diff-merges=<Format>-Option von git-log[1] Diffs generiert und in den Vergleich einbezogen.

Hinweis: Im gängigen Fall ist der Modus remerge am natürlichsten, da er nur die Differenz über das hinaus anzeigt, was Git's Merge-Mechanismus erzeugt hätte. Wenn ein Merge-Commit das Ergebnis eines nicht-konfliktiven git merge ist, repräsentiert der Modus remerge ihn mit einer leeren Differenz.

--remerge-diff

Bequemlichkeitsoption, äquivalent zu --diff-merges=remerge.

--notes[=<Ref>]
--no-notes

Dieses Flag wird an das Programm git log übergeben (siehe git-log[1]), das die Patches generiert.

<Bereich1> <Bereich2>

Vergleicht die von den beiden Bereichen angegebenen Commits, wobei <Bereich1> als ältere Version von <Bereich2> betrachtet wird.

<Rev1>…​<Rev2>

Äquivalent zur Angabe von <Rev2>..<Rev1> und <Rev1>..<Rev2>.

<Basis> <Rev1> <Rev2>

Äquivalent zur Angabe von <Basis>..<Rev1> und <Basis>..<Rev2>. Beachten Sie, dass <Basis> nicht der exakte Verzweigungspunkt der Branches sein muss. Beispiel: Nach dem Rebasen eines Branches my-topic würde git range-diff my-topic@{u} my-topic@{1} my-topic die durch den Rebase eingeführten Unterschiede anzeigen.

git range-diff akzeptiert auch die regulären Diff-Optionen (siehe git-diff[1]), insbesondere die Optionen --color=[<Wann>] und --no-color. Diese Optionen werden bei der Generierung des "Diffs von Patches" verwendet, d.h. zum Vergleichen von Autor, Commit-Nachricht und Diff übereinstimmender alter/neuer Commits. Es gibt derzeit keine Möglichkeit, die meisten Diff-Optionen, die bei der Generierung dieser Patches an git log übergeben werden, anzupassen.

AUSGABENSTABILITÄT

Die Ausgabe des Befehls range-diff kann sich ändern. Sie ist als menschenlesbare Porcelain-Ausgabe gedacht und nicht dafür, über Git-Versionen hinweg verwendet zu werden, um eine textuell stabile range-diff-Ausgabe zu erhalten (im Gegensatz zur Option --stable von git-patch-id[1]). Es gibt auch kein Äquivalent zu git-apply[1] für range-diff; die Ausgabe ist nicht für die maschinelle Lesbarkeit gedacht.

Dies gilt insbesondere, wenn Diff-Optionen übergeben werden. Derzeit können einige Optionen wie --stat als Nebeneffekt eine Ausgabe erzeugen, die im Kontext von range-diff ziemlich nutzlos ist. Zukünftige Versionen von range-diff könnten lernen, solche Optionen auf eine für range-diff spezifische Weise zu interpretieren (z. B. für --stat, um eine menschenlesbare Ausgabe zu erzeugen, die zusammenfasst, wie sich die Diffstat geändert hat).

KONFIGURATION

Dieser Befehl verwendet die Einstellungen diff.color.* und pager.range-diff (letztere ist standardmäßig aktiviert). Siehe git-config[1].

BEISPIELE

Wenn ein Rebase das Auflösen von Merge-Konflikten erforderte, vergleichen Sie die durch den Rebase eingeführten Änderungen direkt danach mit

$ git range-diff @{u} @{1} @

Eine typische Ausgabe von git range-diff würde so aussehen:

-:  ------- > 1:  0ddba11 Prepare for the inevitable!
1:  c0debee = 2:  cab005e Add a helpful message at the start
2:  f00dbal ! 3:  decafe1 Describe a bug
    @@ -1,3 +1,3 @@
     Author: A U Thor <author@example.com>

    -TODO: Describe a bug
    +Describe a bug
    @@ -324,5 +324,6
      This is expected.

    -+What is unexpected is that it will also crash.
    ++Unexpectedly, it also crashes. This is a bug, and the jury is
    ++still out there how to fix it best. See ticket #314 for details.

      Contact
3:  bedead < -:  ------- TO-UNDO

In diesem Beispiel gibt es 3 alte und 3 neue Commits, wobei der Entwickler den 3. entfernt, einen neuen vor den beiden ersten hinzugefügt und die Commit-Nachricht des 2. Commits sowie dessen Diff geändert hat.

Wenn die Ausgabe an ein Terminal geht, ist sie standardmäßig farbkodiert, ähnlich wie die Ausgabe von git diff. Zusätzlich ist die erste Zeile (Hinzufügen eines Commits) grün, die letzte Zeile (Entfernen eines Commits) rot, die zweite Zeile (mit perfekter Übereinstimmung) gelb wie die Commit-Kopfzeile der Ausgabe von git show, und die dritte Zeile färbt den alten Commit rot, den neuen grün und den Rest wie die Commit-Kopfzeile von git show.

Eine naive farbkodierte Diff von Diffs ist tatsächlich etwas schwer zu lesen, da sie die gesamten Zeilen rot oder grün einfärbt. Die Zeile, die "What is unexpected" im alten Commit hinzufügte, ist zum Beispiel komplett rot, auch wenn die Absicht des alten Commits war, etwas hinzuzufügen.

Um dabei zu helfen, verwendet range standardmäßig den Modus --dual-color. In diesem Modus behält die Diff von Diffs die ursprünglichen Diff-Farben bei und präfixiert die Zeilen mit -/+ Markern, deren **Hintergrund** rot oder grün ist, um deutlicher zu machen, dass sie beschreiben, wie sich die Diff selbst geändert hat.

Algorithmus

Die allgemeine Idee ist folgende: Wir generieren eine Kostenmatrix zwischen den Commits in beiden Commit-Bereichen und lösen dann die Zuordnung mit den geringsten Kosten.

Die Kostenmatrix wird wie folgt gefüllt: Für jedes Paar von Commits werden beide Diffs generiert und der "Diff von Diffs" wird mit 3 Kontextzeilen erzeugt, dann wird die Anzahl der Zeilen in diesem Diff als Kosten verwendet.

Um falsch positive Ergebnisse zu vermeiden (z. B. wenn ein Patch entfernt wurde und ein nicht zusammenhängender Patch zwischen zwei Iterationen derselben Patch-Serie hinzugefügt wurde), wird die Kostenmatrix erweitert, um dies zu ermöglichen, indem Einträge mit festen Kosten für vollständige Löschungen/Hinzufügungen hinzugefügt werden.

Beispiel: Seien die Commits 1--2 die erste Iteration einer Patch-Serie und A--C die zweite Iteration. Nehmen wir an, dass A ein Cherry-Pick von 2 ist und C ein Cherry-Pick von 1, aber mit einer kleinen Änderung (z. B. ein behobener Tippfehler). Visualisieren Sie die Commits als bipartiten Graphen:

    1            A

    2            B

		 C

Wir suchen nach der "besten" Erklärung der neuen Serie in Bezug auf die alte. Wir können eine "Erklärung" als Kante im Graphen darstellen:

    1            A
	       /
    2 --------'  B

		 C

Diese Erklärung ist "kostenlos", da es keine Änderung gab. Ebenso könnte C anhand von 1 erklärt werden, aber das verursacht Kosten c>0 aufgrund der Änderung:

    1 ----.      A
	  |    /
    2 ----+---'  B
	  |
	  `----- C
	  c>0

Mathematisch gesehen suchen wir nach einer Art minimaler Kosten-Bipartiten-Zuordnung; 1 wird zu C zu einer bestimmten Kosten zugeordnet usw. Der zugrunde liegende Graph ist tatsächlich ein vollständiger bipartiter Graph; die Kosten, die wir jeder Kante zuordnen, sind die Größe des Diff zwischen den Patches der beiden Commits. Um auch neue Commits zu erklären, führen wir auf beiden Seiten Dummy-Knoten ein:

    1 ----.      A
	  |    /
    2 ----+---'  B
	  |
    o     `----- C
	  c>0
    o            o

    o            o

Die Kosten einer Kante o--C sind die Größe des Diff von C, modifiziert durch einen Fudge-Faktor, der kleiner als 100% sein sollte. Die Kosten einer Kante o--o sind kostenlos. Der Fudge-Faktor ist notwendig, da selbst wenn 1 und C nichts gemeinsam haben, sie immer noch ein paar leere Zeilen und ähnliches gemeinsam haben können, was die Zuordnung 1--C, o--o geringfügig billiger machen kann als 1--o, o--C, auch wenn 1 und C nichts gemeinsam haben. Mit dem Fudge-Faktor benötigen wir einen viel größeren gemeinsamen Teil, um Patches als entsprechend zu betrachten.

Die gesamte benötigte Zeit zur Berechnung dieses Algorithmus ist die Zeit, die benötigt wird, um n+m Commit-Diffs und dann n*m Diff-Patches zu berechnen, zuzüglich der Zeit, die benötigt wird, um die Zuordnung mit den geringsten Kosten zwischen n und m Diffs zu berechnen. Git verwendet eine Implementierung des Jonker-Volgenant-Algorithmus, um das Zuordnungsproblem zu lösen, das eine kubische Laufzeitkomplexität aufweist. Das in diesem Fall gefundene Matching sieht dann so aus:

    1 ----.      A
	  |    /
    2 ----+---'  B
       .--+-----'
    o -'  `----- C
	  c>0
    o ---------- o

    o ---------- o

SIEHE AUCH

git-log[1]

GIT

Teil der git[1] Suite