10.4 Git Internals - Paklêers (Packfiles)

As jy al die instruksies in die voorbeeld van die vorige afdeling gevolg het, behoort jy nou 'n toets-Git-bewaarplek (repository) te hê met 11 objekte — vier blobs, drie bome (trees), drie vasleggings (commits), en een merker (tag):

Git pers die inhoud van hierdie lêers saam met zlib, en jy stoor nie baie nie, so al hierdie lêers neem gesamentlik net 925 grepe (bytes) in beslag. Nou sal jy 'n bietjie meer lywige inhoud by die bewaarplek voeg om 'n interessante kenmerk van Git te demonstreer. Om dit te demonstreer, sal ons die repo.rb lêer van die Grit-biblioteek byvoeg — dit is 'n bronkodelêer van ongeveer 22K:

As jy na die resulterende boom kyk, kan jy die SHA-1-waarde sien wat vir jou nuwe repo.rb blob-objek bereken is:

Jy kan dan git cat-file gebruik om te sien hoe groot daardie objek is:

Op hierdie punt, verander daardie lêer 'n bietjie, en kyk wat gebeur:

Gaan die boom na wat deur daardie laaste vaslegging geskep is, en jy sal iets interessant sien:

Die blob is nou 'n ander blob, wat beteken dat hoewel jy slegs 'n enkele reël aan die einde van 'n lêer met 400 reëls bygevoeg het, Git daardie nuwe inhoud as 'n heeltemal nuwe objek gestoor het:

Jy het nou twee byna identiese 22K-objekte op jou skyf (elk saamgepers tot ongeveer 7K). Sou dit nie lekker wees as Git een van hulle volledig kon stoor nie, maar dan die tweede objek slegs as die verskil (delta) tussen hom en die eerste een?

Dit blyk dat dit wel kan. Die aanvanklike formaat waarin Git objekte op die skyf stoor, word 'n “los” (loose) objekformaat genoem. Soms pak Git egter verskeie van hierdie objekte in 'n enkele binêre lêer genaamd 'n “paklêer” (packfile) saam om spasie te bespaar en meer doeltreffend te wees. Git doen dit as jy te veel los objekte rondlê, as jy die git gc opdrag handmatig uitvoer, of as jy na 'n afgeleë bediener (remote server) push. Om te sien wat gebeur, kan jy Git handmatig vra om die objekte saam te pak deur die git gc opdrag uit te voer:

As jy in jou objects-gids kyk, sal jy sien dat die meeste van jou objekte weg is, en 'n nuwe paar lêers verskyn het:

Die objekte wat oorbly, is die blobs waarna geen vaslegging wys nie — in hierdie geval die “what is up, doc?” voorbeeld en die “test content” voorbeeld-blobs wat jy vroeër geskep het. Omdat jy hulle nooit by enige vasleggings gevoeg het nie, word hulle as hangend (dangling) beskou en word hulle nie in jou nuwe paklêer saamgepak nie.

Die ander lêers is jou nuwe paklêer en 'n indeks (index). Die paklêer is 'n enkele lêer wat die inhoud van al die objekte bevat wat van jou lêerstelsel verwyder is. Die indeks is 'n lêer wat relatiewe beginpunte (offsets) binne daardie paklêer bevat sodat jy vinnig na 'n spesifieke objek kan soek. Wat gaaf is, is dat hoewel die objekte op die skyf voordat jy die gc-opdrag uitgevoer het gesamentlik ongeveer 15K groot was, die nuwe paklêer slegs 7K is. Jy het jou skyfgebruik in die helfte gesny deur jou objekte op te pak.

Hoe doen Git dit? Wanneer Git objekte oppak, soek dit na lêers wat soortgelyke name en groottes het, en stoor slegs die delta’s van een weergawe van die lêer na die volgende. Jy kan in die paklêer kyk en sien wat Git gedoen het om spasie te bespaar. Die git verify-pack loodgietersopdrag (plumbing command) laat jou toe om te sien wat saamgepak is:

Hier verwys die 033b4 blob, wat as jy onthou die eerste weergawe van jou repo.rb lêer was, na die b042a blob, wat die tweede weergawe van die lêer was. Die derde kolom in die afvoer is die grootte van die objek in die paklêer, so jy kan sien dat b042a 22K van die lêer opneem, maar dat 033b4 slegs 9 grepe (bytes) in beslag neem. Wat ook interessant is, is dat die tweede weergawe van die lêer die een is wat ongeskonde (intact) gestoor word, terwyl die oorspronklike weergawe as 'n delta gestoor word — dit is omdat jy heel waarskynlik vinniger toegang tot die mees onlangse weergawe van die lêer sal benodig.

Die regtig lekker ding hiervan is dat dit enige tyd weer herpak kan word. Git sal af en toe jou databasis outomaties herpak, altyd in 'n poging om meer spasie te bespaar, maar jy kan dit ook enige tyd handmatig herpak deur git gc self uit te voer.