Che vogliate o no, il sistema di versionamento Git è oramai diventato uno standard per la revisione del codice.
Questo sistema è stato creato nel “lontano” 2005 da Linus Torvalds come sostituto del metodo di versionamento proprietario che veniva utilizzato precedentemente dal kernel Linux. E la sua larga adozione lo ha reso famoso per essere il software scritto da Torvalds più diffuso in assoluto, ben più dello stesso kernel. Da allora molti passi sono stati fatti, ed ormai il progetto è nelle mani della comunità.
Proprio in questi giorni Brandon Williams, membro del team Git-core, ha pubblicato sulle pagine del blog relativo all’open source di Google l’introduzione alla versione 2 del protocollo Git.
Per l’esattezza le novità impattano il wire protocol di Git, ovvero le metodologie che il protocollo utilizza per clonare, aggiornare e pubblicare le modifiche tra il client ed il server; questa novità, come indicato dall’articolo, risolve una delle parti più inefficienti dell’intero protocollo, oltre a gettare le basi per miglioramenti futuri.
In breve, allo stato attuale (prima di questa versione), ogni volta che un client dava un comando di fetch al server (per avviare lo scaricamento di modifiche pubblicate sul ramo -o branch- sul quale si sta lavorando), questo rispondeva con una lista completa di tutte le referenze sul server, anche nel caso il client stesse richiedendo lo scaricamento delle modifiche su un singolo ramo. Per repository particolarmente estesi (si porta come esempio il repository di Chromium che contiene più di 500 mila branch e tag), questo si traduceva nel server che inviava al client decine di MB di dati che, quest’ultimo, semplicemente ignorava. La nuova versione filtra direttamente le referenze sul server.
La nuova versione migliora di 3 volte le performance per questo tipo di operazioni, anche su repository particolarmente grandi. Inoltre si ha una riduzione di 8 volte sui byte non riguardanti reali dati contenenti nei file in gestione al versionamento (non-packfile).
Nonostante Google abbia già migrato tutti i suoi server Git a questo nuovo protocollo, restava da gestire un grosso problema: come mantenere la retrocompatibilità del client con i server che non lo gestiscono. Già, perché pare il protocollo Git sia particolarmente rigido (ne ha gettato le basi Torvalds, sarà un caso?) e l’aggiunta di campi alla richiesta iniziale (ad esempio per richiedere di utilizzare una versione di protocollo rispetto ad un’altra) rompe la compatibilità con la versione precedente.
E’ interessante nell’articolo leggere come è stata sfruttata l’applicazione un fix di un bug introdotto nel 2006, e risolto nel 2009, per utilizzare un comportamento inaspettato del protocollo e di come questo, una volta applicata questa fix, gestisce i byte NUL (\0) ala fine della stringa. Potremmo dire che viene utilizzato, a fin di bene, un bug nella patch, facendo in modo che i server Git compatibili con versioni <2 di protocollo ignorino la stringa, mentre quelli nuovi la possano leggere per capire se il client sta facendo richieste particolari.
Questo protocollo sarà ufficialmente supportato dalla versione 2.18 di Git ma, se volete, potete già provarlo tirando giù il branch master dal repository ufficiale su GitHub.
Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.
Lascia un commento