Dopo due mesi di sviluppo, è stato rilasciato Git 2.51, un sistema distribuito di gestione dei testi sorgente. Git si distingue per l'alta performance e offre strumenti per lo sviluppo non lineare, basati su ramificazioni e fusioni. Per garantire l'integrità della storia e la resistenza a modifiche retroattive, utilizza l'hashing implicito di tutta la storia precedente in ogni commit, oltre alla certificazione tramite firme digitali degli sviluppatori per singoli tag e commit. Il codice di Git è distribuito sotto licenza GPLv2+.
Rispetto alla versione precedente, nella nuova release sono stati accolti 506 cambiamenti, realizzati con la partecipazione di 91 sviluppatori (21 dei quali hanno partecipato allo sviluppo di Git per la prima volta). Le principali novità (1, 2, 3):
- È stata migliorata la performance dei comandi «git push» e «git fetch» nei repository con un grande numero di riferimenti. L'accelerazione è stata ottenuta grazie all'aggiornamento dei riferimenti in modalità batch, in cui più riferimenti vengono elaborati in una singola transazione, invece di crearne una separata per ciascun aggiornamento. L'ottimizzazione ha notevolmente aumentato la velocità del backend «reftable», che ora supera in performance il backend «files». Ad esempio, in un repository di test con 10.000 riferimenti, la performance di «git fetch» utilizzando il backend «reftable» è aumentata di 22 volte, mentre con il backend «files» è aumentata di 1,25 volte. Per «git push», l'aumento è stato di 18 e 1,21 volte, rispettivamente.
- È stato proposto un nuovo metodo di imballaggio nei file pack di parti del repository non collegate a oggetti irraggiungibili, per i quali non ci sono riferimenti nel repository (nessun ramo o tag li punta). Le informazioni sugli oggetti irraggiungibili sono conservate in file pack separati («cruft packs»), il che comportava la necessità di rifletterli negli indici multi-pack MIDX (multi-pack index) per coprire oggetti che inizialmente erano irraggiungibili e conservati solo nel cruft-pack, ma che sono diventati raggiungibili dopo un commit che li punta.
Nella nuova versione, durante la ri-imballaggio dei file pack, si garantisce la conservazione di copie aggiuntive degli oggetti raggiungibili, conservati solo nei file cruft. Tale modifica garantisce che nel set di file pack utilizzati per conservare oggetti raggiungibili non ci siano oggetti che puntano ad altri oggetti conservati al di fuori di questo set. Per escludere il contenuto irraggiungibile dei file cruft dagli indici multi-pack (MIDX), è stata proposta un'impostazione «repack.MIDXMustContainCruft», che consente di ridurre significativamente la dimensione di tali indici. L'attivazione di questa impostazione nei repository GitHub ha permesso di ridurre la dimensione degli indici MIDX del 38%, accelerando la scrittura negli indici MIDX del 35% e migliorando la performance di lettura del 5%.
- Nella squadra «git pack-objects» è stata aggiunta l'opzione «—path-walk», che introduce un nuovo metodo di raccolta di informazioni sugli oggetti durante la ri-imballaggio dei file pack. Invece di scorrere gli oggetti in base alle revisioni, utilizzando la modalità «—path-walk», gli oggetti vengono esaminati seguendo i percorsi dei file, permettendo di imballare tutti gli oggetti con lo stesso percorso di file in un'unica operazione. Questo approccio consente di evitare l'euristica che utilizza l'hashing per determinare la correlazione di un oggetto con il suo percorso di file, e di non dover ordinare gli oggetti prima dell'imballaggio. Quando si utilizza la modalità «—path-walk», la dimensione dei file pack generati è notevolmente inferiore rispetto alla raggruppamento di oggetti tramite hash.
- È stato definito un formato per lo scambio di stati salvati dell'albero di lavoro e degli indici nel repository, creati con il comando «git stash». Il nuovo formato consente di codificare le modifiche salvate (stash-log) come una sequenza di commit. Per l'importazione e l'esportazione sono state proposte le sottocomandi «git stash import» e «git stash export», che possono essere utilizzate per trasferire stati salvati da un sistema all'altro e eseguire operazioni di push o pull con questi stati come se fossero normali rami o tag. git stash export —to-ref refs/stashes/my-stash git push origin refs/stashes/my-stash … git fetch origin ‘+refs/stashes/*:refs/stashes/*’ git stash import refs/stashes/my-stash
- Nel comando «git cat-file», che visualizza il contenuto di oggetti specifici, con le opzioni «—batch» e «—batch-check» è stata implementata la possibilità di visualizzare informazioni su oggetti mancanti (ad esempio, a causa di un danneggiamento del repository) e submoduli. In precedenza, quando si specificava il percorso di un submodulo, il comando «git cat-file —batch-check» restituiva «missing», mentre ora mostrerà l'identificativo dell'oggetto.
- Nel comando «git log» sono state implementate ottimizzazioni basate su filtri di Bloom per accelerare la ricerca nella cronologia delle modifiche quando si specificano filtri con più percorsi di file, ad esempio, «git log — path/to/a path/to/b».
- Le comandi «git switch» e «git restore» sono state stabilizzate e vengono presentate come equivalenti moderni a «git checkout», separando funzionalità poco correlate di questo comando, come la manipolazione dei rami (cambio e creazione) e il ripristino dei file nella directory di lavoro.
- La comando «git whatchanged», equivalente a «git log —raw», è stata dichiarata obsoleta ed è programmata per essere rimossa nella versione Git 3.0.
- Alla comando «git for-each-ref» è stata aggiunta l'opzione «—start-after», che può essere utilizzata insieme all'opzione «—count» per facilitare la visualizzazione pagina per pagina.
- Alle comandi «git merge» e «git pull» è stata aggiunta l'opzione «—compact-summary» per utilizzare un formato compatto di riepilogo delle modifiche anziché il formato diffstat.
- È consentito l'uso della parola chiave «bool» nel codice sorgente di Git, come previsto dallo standard C99. Inoltre, alcune funzionalità di C99, utilizzate in modo sperimentale in Git, sono state documentate (ad esempio, nel 2026 è previsto il permesso di utilizzare costruzioni come «(struct foo){ .member = value };»). Un compilatore che supporta C99 è obbligatorio per Git dal 2021, ma le funzionalità della specifica C99 vengono implementate con cautela per mantenere la compatibilità con i compilatori che supportano solo parzialmente questo standard.
- Sono state apportate modifiche alle regole di accettazione dei patch che consentono l'invio di patch con uno pseudonimo, e non solo con il nome reale dello sviluppatore. La modifica è conforme alle regole di accettazione dei patch nel kernel Linux.
- È stata aggiornata la lista delle modifiche non compatibili che saranno applicate nella versione Git 3.0. Tra i cambiamenti significativi previsti per il rilascio di Git 3.0 c'è il passaggio predefinito agli identificatori degli oggetti basati sull'algoritmo di hashing SHA-256 quando si inizializzano nuovi repository e l'implementazione del formato «reftable» per memorizzare i riferimenti a rami e tag nel repository (utilizzato lo storage a blocchi del progetto JGit, ottimizzato per gestire un numero molto elevato di riferimenti).
Fonte: opennet.ru
