git-gc -Städa onödiga filer och optimera det lokala kodförrådet

Kör ett antal hushållnings-uppgifter inom det aktuella kodförrådet, såsom att komprimera filrevisioner (för att minska diskutrymme och öka prestanda), ta bort oåtkomliga objekt som kan ha skapats från tidigare anrop av git add, packa referenser, trimma reflog, återställa metadata eller inaktuella fungerande träd. Kan också uppdatera hjälpindex såsom incheckning-grafen.

När vanliga porslinsoperationer som skapar objekt körs, kontrollerar de om kodförrådet har vuxit avsevärt sedan det senaste underhållet, och i så fall kör de git gc automatiskt. Se gc.auto nedan för hur du inaktiverar detta beteende.

Att köra git gc manuellt borde bara behövas när man lägger till objekt i ett kodförråd utan att regelbundet köra sådana porslins-kommandon, för att göra en engångsoptimering av kodförrådet, eller t.ex. för att rensa upp en suboptimal massimport. Se avsnittet "PAKETFILs-optimering" i git-fast-import[1] för mer information om importfallet.

När alternativet --aggressive anges, kommer git-repack[1] att anropas med flaggan -f, som i sin tur skickar --no-reuse-delta till git-pack-objects[1]. Detta kommer att kasta bort alla befintliga deltan och beräkna dem om, vilket i sin tur leder till att mycket mer tid spenderas på ompackningen.

Effekterna av detta är mestadels ihållande, t.ex. när paket och lösa föremål slås samman till ett annat paket kan de befintliga deltana i det paketet återanvändas, men det finns också olika fall där vi istället kan välja ett suboptimalt delta från ett nyare paket.

Dessutom, om man anger --aggressive, justeras alternativen --depth och --window som skickas till git-repack[1]. Se inställningarna för gc.aggressiveDepth och gc.aggressiveWindow nedan. Genom att använda en större fönsterstorlek är det mer troligt att vi hittar mer optimala deltan.

Det är förmodligen inte värt att använda det här alternativet på ett givet kodförråd utan att köra skräddarsydda prestanda-tester på det. Det tar mycket mer tid, och den resulterande utrymmes-/delta-optimeringen kan vara värd det, men kanske inte. Att inte använda detta alls är rätt avvägning för de flesta användare och deras fövar.

Allt under den här raden i det här avsnittet är selektivt inkluderat från dokumentationen git-config[1]. Innehållet är detsamma som det som finns där:

git gc försöker verkligen att inte ta bort objekt som refereras någonstans i ditt kodförråd. I synnerhet kommer det inte bara att behålla objekt som refereras av din nuvarande uppsättning grenar och taggar, utan även objekt som refereras av indexet, fjärrspårningsgrenar, reflogs (som kan referera till incheckningar i grenar som senare ändrades eller omspunnas) och allt annat i namnrymden refs/*. Observera att en anteckning (av den typ som skapas av git notes) som är kopplad till ett objekt inte bidrar till att hålla objektet vid liv. Om du förväntar dig att vissa objekt ska tas bort och de inte gör det, kontrollera alla dessa platser och avgör om det är vettigt i ditt fall att ta bort dessa referenser.

Å andra sidan, när git gc körs samtidigt med en annan process, finns det en risk att den tar bort ett objekt som den andra processen använder men inte har skapat en referens till. Detta kan bara orsaka att den andra processen misslyckas eller skada kodförrådet om den andra processen senare lägger till en referens till det borttagna objektet. Git har två funktioner som avsevärt minskar detta problem:

Dessa funktioner utgör dock inte en komplett lösning, så användare som kör kommandon samtidigt måste leva med en viss risk för korruption (vilket verkar vara låg i praktiken).

Kommandot git gc --auto kör kroken pre-auto-gc. Se githooks[5] för mer information.

git-prune[1] git-reflog[1] git-repack[1] git-rerere[1]

En del av git[1]-sviten