Wenn nur 1 Baum angegeben ist, verhält sich git read-tree so, als ob der Benutzer nicht -m angegeben hätte, mit dem Unterschied, dass, wenn der ursprüngliche Index einen Eintrag für einen bestimmten Pfadnamen hat und die Inhalte des Pfads mit dem eingelesenen Baum übereinstimmen, die Stat-Informationen aus dem Index verwendet werden. (Anders ausgedrückt: Die Stat()s des Index haben Vorrang vor denen des gemergten Baums).

Das bedeutet, dass, wenn Sie einen git read-tree -m <newtree> ausführen, gefolgt von einem git checkout-index -f -u -a, git checkout-index nur die Dinge auscheckt, die sich wirklich geändert haben.

Dies dient dazu, unnötige Fehlalarme zu vermeiden, wenn git diff-files nach git read-tree ausgeführt wird.

Typischerweise wird dies als git read-tree -m $H $M aufgerufen, wobei $H der Head-Commit des aktuellen Repositories ist und $M der Head eines externen Baums, der einfach vor $H liegt (d.h. wir sind in einer Fast-Forward-Situation).

Wenn zwei Bäume angegeben sind, teilt der Benutzer git read-tree Folgendes mit:

In diesem Fall stellt der Befehl git read-tree -m $H $M sicher, dass keine lokale Änderung als Ergebnis dieses "Merges" verloren geht. Hier sind die "Carry Forward"-Regeln, wobei "I" den Index bezeichnet, "clean" bedeutet, dass Index und Arbeitsverzeichnis übereinstimmen, und "exists"/"nothing" sich auf die Anwesenheit eines Pfades im angegebenen Commit beziehen

In allen Fällen "Keep Index" bleibt der Indexeintrag wie in der ursprünglichen Indexdatei. Wenn der Eintrag nicht aktuell ist, behält git read-tree die Kopie im Arbeitsverzeichnis intakt, wenn es unter dem Flag -u operiert.

Wenn diese Form von git read-tree erfolgreich zurückkehrt, können Sie sehen, welche der von Ihnen vorgenommenen "lokalen Änderungen" übernommen wurden, indem Sie git diff-index --cached $M ausführen. Beachten Sie, dass dies nicht unbedingt dem entspricht, was git diff-index --cached $H vor einem solchen Zwei-Baum-Merge ergeben hätte. Dies liegt an den Fällen 18 und 19 – wenn Sie die Änderungen bereits in $M hatten (z. B. per E-Mail in Patch-Form erhalten), hätte git diff-index --cached $H Sie vor diesem Merge über die Änderung informiert, aber sie würde nach dem Zwei-Baum-Merge nicht in der Ausgabe von git diff-index --cached $M erscheinen.

Fall 3 ist etwas knifflig und bedarf einer Erklärung. Das Ergebnis dieser Regel sollte logischerweise das Entfernen des Pfads sein, wenn der Benutzer die Entfernung des Pfads gestaged hat und dann zu einem neuen Branch wechselt. Das würde jedoch den anfänglichen Checkout verhindern, daher wird die Regel modifiziert, um M (neuer Baum) nur dann zu verwenden, wenn der Inhalt des Index leer ist. Andernfalls bleibt die Entfernung des Pfads erhalten, solange $H und $M gleich sind.

Jeder "Index"-Eintrag hat zwei Bits für den "Stage"-Status. Stage 0 ist der normale, und ist der einzige, den Sie in irgendeiner normalen Verwendung sehen würden.

Wenn Sie jedoch git read-tree mit drei Bäumen verwenden, beginnt der "Stage" bei 1.

Das bedeutet, dass Sie Folgendes tun können:

und Sie erhalten einen Index mit allen Einträgen von <tree1> in "Stage 1", allen Einträgen von <tree2> in "Stage 2" und allen Einträgen von <tree3> in "Stage 3". Beim Mergen eines anderen Branches in den aktuellen Branch verwenden wir den Baum des gemeinsamen Vorfahren als <tree1>, den aktuellen Branch-Head als <tree2> und den Head des anderen Branches als <tree3>.

Darüber hinaus hat git read-tree spezielle Logik, die besagt: Wenn eine Datei in allen drei Bäumen in den folgenden Zuständen übereinstimmt, "kollabiert" sie zurück zu "Stage 0".

Der Befehl git write-tree weigert sich, einen unsinnigen Baum zu schreiben, und beschwert sich über unmerged Einträge, wenn er einen einzelnen Eintrag sieht, der nicht Stage 0 ist.

OK, das klingt alles wie eine Sammlung völlig unsinniger Regeln, aber es ist tatsächlich genau das, was Sie wollen, um einen schnellen Merge durchzuführen. Die verschiedenen Stages repräsentieren den "Ergebnisbaum" (Stage 0, auch "merged" genannt), den ursprünglichen Baum (Stage 1, auch "orig" genannt) und die beiden Bäume, die Sie zusammenführen möchten (Stage 2 bzw. 3).

Die Reihenfolge der Stages 1, 2 und 3 (daher die Reihenfolge der drei <tree-ish> Kommandozeilenargumente) ist signifikant, wenn Sie einen 3-Wege-Merge mit einer bereits gefüllten Indexdatei starten. Hier ist eine Übersicht, wie der Algorithmus funktioniert.

Normalerweise würden Sie git merge-index mit einem bereitgestellten git merge-one-file verwenden, um diesen letzten Schritt durchzuführen. Das Skript aktualisiert die Dateien im Arbeitsverzeichnis, während es jeden Pfad zusammenführt, und am Ende eines erfolgreichen Merges.

Wenn Sie einen 3-Wege-Merge mit einer bereits gefüllten Indexdatei starten, wird davon ausgegangen, dass diese den Zustand der Dateien in Ihrem Arbeitsverzeichnis repräsentiert, und Sie können sogar Dateien mit Änderungen haben, die nicht im Index erfasst sind. Es wird ferner davon ausgegangen, dass dieser Zustand vom Stage 2-Baum abgeleitet ist. Der 3-Wege-Merge weigert sich zu laufen, wenn er einen Eintrag in der ursprünglichen Indexdatei findet, der nicht mit Stage 2 übereinstimmt.

Dies geschieht, um zu verhindern, dass Sie Ihre Work-in-Progress-Änderungen verlieren und Ihre zufälligen Änderungen in einen nicht zusammenhängenden Merge-Commit einbringen. Zur Veranschaulichung, nehmen wir an, Sie starten von dem, was zuletzt in Ihrem Repository committet wurde.

Sie nehmen zufällige Bearbeitungen vor, ohne git update-index auszuführen. Und dann bemerken Sie, dass die Spitze Ihres "upstream"-Baums seit dem letzten Pull fortgeschritten ist.

Ihr Arbeitsverzeichnis basiert immer noch auf Ihrem HEAD ($JC), aber Sie haben einige Bearbeitungen seitdem. Der Drei-Wege-Merge stellt sicher, dass Sie seit $JC keine Indexeinträge hinzugefügt oder geändert haben und führt dann, wenn nicht, das Richtige durch. Also mit der folgenden Sequenz

würde das, was Sie committen, ein reiner Merge zwischen $JC und $LT ohne Ihre Work-in-Progress-Änderungen sein, und Ihr Arbeitsverzeichnis würde auf das Ergebnis des Merges aktualisiert.

Wenn Sie jedoch lokale Änderungen im Arbeitsverzeichnis haben, die durch diesen Merge überschrieben würden, weigert sich git read-tree zu laufen, um den Verlust Ihrer Änderungen zu verhindern.

Mit anderen Worten, Sie müssen sich keine Sorgen machen, was nur im Arbeitsverzeichnis existiert. Wenn Sie lokale Änderungen in einem Teil des Projekts haben, der nicht am Merge beteiligt ist, stören Ihre Änderungen den Merge nicht und bleiben erhalten. Wenn sie sich **doch** stören, beginnt der Merge gar nicht erst (git read-tree meckert laut und schlägt fehl, ohne etwas zu ändern). In einem solchen Fall können Sie einfach fortfahren, was Sie gerade getan haben, und wenn Ihr Arbeitsverzeichnis bereit ist (d. h. Sie Ihre Arbeit abgeschlossen haben), versuchen Sie den Merge erneut.