10.6 Git Binnenwerk - Uitwisseling protocollen

ALs je een repository opzet die alleen gelezen hoeft te worden via HTTP, is het domme protocol het meest waarschijnlijke zijn die zal worden gebruikt. Dit protocol wordt “dom” genoemd omdat het geen Git-specifieke code nodig heeft aan de kant van de server tijdens het uitwisselingsproces; het fetch proces is een reeks van HTTP GET requests, waar het werkstation aannames mag doen over de inrichting van de Git repository op de server.

Laten we het http-fetch proces voor de simplegit library eens volgen:

Het eerste wat dit commando doet is het info/refs bestand pullen. Dit bestand wordt geschreven door het update-server-info commando, wat de reden is waarom je dit als post-receive hook moet activeren om het uitwisselen via HTTP goed te laten werken:

Nu heb je een lijst met de remote referenties en SHA-1 waarden. Vervolgens ga je op zoek naar de HEAD referentie zodat je weet wat je moet uitchecken als je klaar bent:

Je moet de master-branch uitchecken als je het proces hebt voltooid. Op dit punt ben je gereed om het proces te doorlopen. Omdat je vertrekpunt het ca82a6 commit object is die je in het info/refs bestand zag, begin je met die te fetchen:

Je krijgt een object terug - dat object is in het losse (loose) formaat op de server, en je hebt het met een statische HTTP GET request gefetcht. Je kunt het nu met zlib-uncompress uitpakken, de header ervan afhalen, en naar de commit inhoud kijken:

Vervolgens heb je nog twee objecten op te halen - cfda3b, wat de boom met inhoud is waar de commit die we zojuist opgehaald hebben naar wijst, en 085bb3, wat de ouder-commit is:

En daarmee krijg je je volgende commit object. Haal het boom-object op:

Oeps, het ziet er naar uit dat het boom-object niet in het losse formaat op de server is, dus je krijgt een 404 antwoord. Hier zijn een aantal mogelijke oorzaken voor - het object kan in een andere repository zitten, of het zou in een packfile in deze repository kunnen zitten. Git controleert eerst of er alternatieven zijn opgegeven:

Dit geeft een lijst met alternatieve URLs terug, Git controleert daar op losse bestanden en packfiles - dit is een aardig mechanisme voor projecten die forks zijn van elkaar zijn om objecten te delen op schijf. Echter, omdat er in dit geval geen alternatieven worden gegeven, moet het object in een packfile zitten. Om te zien welke packfiles er beschikbaar zijn op deze server, moet je het objects/info/packs bestand te pakken krijgen, waar een opsomming hiervan in staat (wat ook door de update-server-info wordt gegenereerd):

Er is maar één packfile op de server, dus jouw object moet daar wel in zitten, maar je gaat het index bestand toch controleren om er zeker van te zijn. Dit is ook handig als je meerdere packfiles op de server hebt, omdat je dan kan zien welk packfile het object wat je nodig hebt bevat:

Nu je de packfile index hebt, kan je kijken of jouw object daar in zit - omdat de index de SHA-1 waarden van de objecten bevat die in de packfile zitten en de relatieve afstand (offset) naar deze objecten. Jouw object is er, dus ga je verder en haalt de hele packfile op:

Je hebt je boom object, dus je gaat verder met je commits af te lopen. Die zitten ook allemaal in de packfile die je zojuist hebt gedownload, dus je hoeft geen verzoeken meer te doen naar de server. Git checkt een werk-kopie van de master-branch uit waarnaar werd verwezen door de HEAD referentie die je aan het begin hebt gedownload.

Het domme protocol is eenvoudig, maar een beetje inefficiënt, het kan geen gegevens aan die van het werkstation naar de server moet worden geschreven. Het slimme protocol is een meer gebruikelijke methode van gegevens uit te wisselen, maar het heeft een proces aan de remote kant nodig die op de hoogte is van Git - het moet lokale gegevens kunnen lezen, uitvinden wat het werkstation al heeft en nog nodig heeft, en een op maat gemaakte packfile hiervoor maken. Er zijn twee groepen van processen voor het uitwisselen van gegevens: een paar voor het uploaden van gegevens en een paar voor het downloaden van gegevens.

Deze paragraaf bevat een zeer basale overzicht van de uitwisselings-protocollen. Het protocol omvat vele andere mogelijkheden, zoals multi_ack of side-band mogelijkheden, maar de behandeling hiervan valt buiten het bestek van dit boek. We hebben geprobeerd je een idee te geven van het globale over-en-weer tussen werkstation en server; als je hierover meer wilt weten, dan kan je bijvoorbeeld een kijkje nemen in de Git broncode.