10.4 Git Binnenwerk - Packfiles

Als je alle instructies in het voorbeeld van de hiervoorgaande sectie hebt gevolgd, zou je nu een test Git repository moeten hebben met 11 objecten — vier blobs, drie trees, drie commits en een tag:

Git comprimeert de inhoud van deze bestanden met zlib, en je slaat niet veel op, dus al deze bestanden nemen samen maar 925 bytes in beslag. Je zult wat lijviger inhoud aan de repository toevoegen om een interessante mogelijkheid van Git te demonstreren. Om het te demonstreren zullen we het repo.rb bestand van de Grit library toevoegen — dit is een broncode bestand van ongeveer 22K.

Als je naar de resulterende tree kijkt, zie je de SHA-1 waarde die je repo.rb bestand heeft gekregen voor het nieuwe blob object:

Je kunt daarna git cat-file gebruiken om te zien hoe groot dat object is:

Wijzig nu dat bestand een beetje, en kijk wat er gebeurt:

Kijk naar de tree die door die commit gemaakt is, en je zult iets interessants zien:

De blob is nu een andere blob, wat inhoudt dat ondanks dat je maar een enkele regel aan het eind van een bestand van 400 regels hebt toegevoegd, Git de nieuwe inhoud als een volledig nieuw object heeft opgeslagen.

Je hebt nu twee vrijwel identieke objecten van 22K op je schijf staan (elk gecomprimeerd tot ongeveer 7K). Zou het niet aardig zijn als Git een van deze volledig zou opslaan maar dan het tweede object alleen als de delta tussen deze en de eerste?

Laat dit nu ook het geval zijn. Het initiële formaat waar Git objecten op schijf bewaard wordt een “loose” (los, ruimzittend) object formaat genoemd. Echter, van tijd tot tijd pakt Git een aantal van deze bestanden in een enkele binair bestand “packfile” genaamd in met als doel ruimte te besparen en meer efficiënt te zijn. Git doet dit als je teveel losse bestanden hebt, als je het git gc commando handmatig aanroept, of als je naar een remote server pusht. Om te zien wat er gebeurt, kan je Git handmatig vragen om de objecten in te pakken door het git gc commando aan te roepen:

Als je in je objecten directory kijkt, zal je zien dat de meeste van je objecten zijn verdwenen en dat er een aantal andere bestanden zijn verschenen:

De objecten die zijn overgebleven zijn de blobs waar geen enkele commit nog naar wijst — in dit geval de blobs van het “what is up, doc?”-voorbeeld en het “test content”-voorbeeld die je eerder hebt gemaakt. Omdat je ze nooit aan enige commit hebt toegevoegd, worden ze beschouwd als bungelend (dangling) en worden ze niet in je nieuwe packfile ingepakt.

De andere bestanden zijn je nieuwe packfile en een index. Het packfile bestand is een enkel bestand met daarin de inhoud van al de objecten die zijn verwijderd van je bestandssysteem. De index is een bestand die de relatieve beginpunten bevat in die packfile zodat je snel naar een specifiek object kunt zoeken. Wat cool is, is dat ondanks dat de bestanden op schijf voordat je het gc commando aanriep samen ongeveer 15K groot waren, het nieuwe packfile bestand maar 7K is. Je hebt schijfruimte-gebruik tot de helft verminderd door je objecten in te pakken.

Hoe doet Git dit? Als Git objecten inpakt, kijkt het naar bestanden die vergelijkbare namen en grootte hebben, en slaat daarvan alleen de delta’s tussen de ene versie van het bestand en de andere op. Je kunt in het packfile bestand kijken en zien wat Git gedaan heeft om schijfruimte te besparen. Het git verify-pack binnenwerk commando stelt je in staat om te zien wat er ingepakt is:

Hier verwijst de 033b4 blob die, als je het je nog kunt herinneren, de eerste versie van je repo.rb bestand is, naar de b042a blob, wat de tweede versie van het bestand was. De derde kolom in de uitvoer is de grootte van het object in het packfile bestand, dus je kunt zien dat b042a 22K van het bestand inneemt, aar dat 033b4 maar 9 bytes in beslag neemt. Wat ook interessant is, is dat de tweede versie van het bestaand degene is die intact opgeslagen is, terwijl de orginele versie is opgeslagen als een delta — de reden hiervoor is dat het waarschijnlijker is dat je snellere toegang nodig hebt naar de meest recente versie van het bestand.

Het echte leuke van dit is, is dat het op elk gewenste moment weer opnieuw kan worden ingepakt. Git zal van op gezette tijden je database automatisch opnieuw inpakken, altijd met het doel nog meer ruimte te besparen, maar je kunt ook handmatig opnieuw laten inpakken door git gc zelf aan te roepen.