Om endast ett träd anges fungerar git read-tree som om användaren inte hade angett -m, utom att om det ursprungliga indexet har en post för ett visst sökvägsnamn och innehållet i sökvägen matchar trädet som läses, används stat-informationen från indexet. (Med andra ord har indexets stat() företräde framför de sammanslagna trädens.)

That means that if you do a git read-tree -m <newtree> followed by a git checkout-index -f -u -a, the git checkout-index only checks out the stuff that really changed.

Det här används för att undvika onödiga falska träffar när git diff-files körs efter git read-tree.

Vanligtvis anropas detta som git read-tree -m $H $M, där $H är HEAD-incheckningen för det aktuella kodförrådet och $M är spetsen för ett främmande träd, som helt enkelt ligger före $H (d.v.s. vi är i en snabbspolningssituation).

När två träd anges, säger användaren följande till git read-tree:

I det här fallet säkerställer kommandot git read-tree -m $H $M att inga lokala ändringar går förlorade som resultat av den här "sammanslagningen". Här är reglerna för att föra vidare ändringar, där "I" betecknar indexet, "clean" betyder att index och arbetsträd sammanfaller, och "exists"/"nothing" hänvisar till om en sökväg finns i den angivna incheckningen:

I alla fall med "behåll index" lämnas indexposten som i den ursprungliga indexfilen. Om posten inte är uppdaterad behåller git read-tree kopian i arbetsträdet intakt när kommandot körs med -u.

När denna form av git read-tree returnerar korrekt kan du se vilka av de "lokala ändringarna" som du gjorde som överfördes genom att köra git diff-index --cached $M. Observera att detta inte nödvändigtvis matchar vad git diff-index --cached $H skulle ha producerat före en sådan tvåträdssammanslagning. Detta beror på fallen 18 och 19 — om du redan hade ändringarna i $M (t.ex. kanske du hämtade dem via e-post i en patchform), skulle git diff-index --cached $H ha berättat om ändringen före denna sammanslagning, men den skulle inte visas i git diff-index --cached $M-utdata efter tvåträdssammanslagningen.

Fall 3 är lite knepigt och behöver förklaras. Resultatet av denna regel borde logiskt sett vara att ta bort sökvägen om användaren stegvis tog bort sökvägen och sedan bytte till en ny gren. Detta kommer dock att förhindra att den initiala utcheckningen sker, så regeln modifieras för att endast använda M (nytt träd) när innehållet i indexet är tomt. Annars bibehålls borttagningen av sökvägen så länge $H och $M är desamma.

Varje "index"-post har två bitar av "steg"-tillstånd. Steg 0 är det normala, och är det enda du skulle se vid någon form av normal användning.

Men när du kör git read-tree med tre träd börjar "steg" på 1.

Det här betyder att du kan göra

och du får ett index med alla <träd1>-poster i "steg1", alla <träd2>-poster i "steg2" och alla <träd3>-poster i "steg3". När vi sammanfogar en annan gren in i den aktuella grenen använder vi det gemensamma förfaderträdet som <träd1>, den aktuella grenens spets som <träd2> och den andra grenens spets som <träd3>.

Dessutom har git read-tree specialfallslogik som säger: om du ser en fil som matchar i alla avseenden i följande tillstånd, "kollapsar" den tillbaka till "stage0":

Kommandot git write-tree vägrar att skriva ett meningslöst träd, och det kommer att klaga på ej sammanslagna poster om det ser en enskild post som inte är steg 0.

Okej, allt detta låter som en samling totalt meningslösa regler, men det är faktiskt precis vad du vill ha för att göra en snabb sammanslagning. De olika stegen representerar "resultatträdet" (steg 0, även kallat "sammanslaget"), det ursprungliga trädet (steg 1, även kallat "orig") och de två träden du försöker sammanfoga (steg 2 respektive 3).

Ordningen på steg 1, 2 och 3 (därav ordningen med tre kommandoradsargument av typen <trädlikt>) är viktig när du startar en trevägssammanslagning med en indexfil som redan är ifylld. Här är en översikt över hur algoritmen fungerar:

Normalt använder du git merge-index med git merge-one-file för att göra det sista steget. Skriptet uppdaterar filerna i arbetsträdet allt eftersom varje sökväg sammanfogas, och vid slutet av en lyckad sammanslagning.

När du startar en 3-vägssammanslagning med en indexfil som redan är ifylld, antas det att den representerar filernas tillstånd i ditt arbetsträd, och du kan till och med ha filer med ändringar som inte registrerats i indexfilen. Det antas vidare att detta tillstånd "härleds" från steg 2-trädet. 3-vägssammanslagningen vägrar att köras om den hittar en post i den ursprungliga indexfilen som inte matchar steg 2.

Det här görs för att hindra att du förlorar dina pågående ändringar och blandar in slumpmässiga ändringar i en orelaterad sammanslagningsincheckning. För att illustrera: anta att du börjar från det som senast checkades in i ditt kodförråd:

Du gör slumpmässiga redigeringar utan att köra git update-index. Och sedan märker du att toppen på ditt "uppströms"-träd har avancerat sedan du hämtade från honom:

Ditt arbetsträd är fortfarande baserat på din HEAD ($JC), men du har gjort några ändringar sedan dess. Trevägssammanslagning säkerställer att du inte har lagt till eller ändrat indexposter sedan $JC, och om du inte har det, gör du rätt sak. Så med följande sekvens:

Det du då checkar in är en ren sammanslagning mellan $JC och $LT utan dina pågående ändringar, och ditt arbetsträd uppdateras till sammanslagningens resultat.

Om du däremot har lokala ändringar i arbetsträdet som skulle skrivas över av den här sammanslagningen vägrar git read-tree att köras för att förhindra att ändringarna går förlorade.

Med andra ord finns ingen anledning att oroa sig för sådant som bara finns i arbetsträdet. Har du lokala ändringar i en del av projektet som inte berörs av sammanslagningen stör de inte sammanslagningen och behålls intakta. När de gör det startar sammanslagningen inte ens ("git read-tree" klagar tydligt och misslyckas utan att ändra något). I ett sådant fall kan du fortsätta med det du höll på med och försöka sammanslagningen igen när arbetsträdet är klart (d.v.s. när det pågående arbetet är färdigt).