Dopo due mesi di sviluppo, è stato presentato il rilascio del sistema distribuito di gestione delle versioni del codice sorgente Git 2.51. Git si distingue per le sue elevate prestazioni e offre strumenti per lo sviluppo non lineare, basati su ramificazioni e fusioni di rami. Per garantire l'integrità della storia e la resistenza alle modifiche retroattive, si utilizza l'hashing implicito dell'intera storia precedente in ogni commit, nonché la verifica tramite firme digitali degli sviluppatori per i singoli tag e commit. Il codice di Git è distribuito sotto licenza GPLv2+.
Rispetto alla versione precedente, nella nuova versione sono stati apportati 506 cambiamenti, frutto del lavoro di 91 sviluppatori (21 dei quali hanno partecipato per la prima volta allo sviluppo di Git). Le principali novità (1, 2, 3):
- Le prestazioni dei comandi "git push" e "git fetch" sono state migliorate nei repository con un gran numero di riferimenti. L'accelerazione è stata ottenuta grazie all'aggiornamento dei riferimenti in modalità batch, che consente di gestire più riferimenti in una sola transazione, invece di creare una transazione separata per ciascun aggiornamento. L'ottimizzazione ha aumentato notevolmente la velocità del backend "reftable", che ora supera il backend "files" in termini di prestazioni. Ad esempio, in un repository di test con 10.000 riferimenti, le prestazioni di "git fetch" utilizzando il backend "reftable" sono aumentate di 22 volte, mentre utilizzando il backend "files" è aumentato di 1,25 volte. Per "git push", il guadagno è stato rispettivamente di 18 e 1,21 volte.
- È stato proposto un nuovo metodo di imballaggio in pacchetti (pack-files) per le parti del repository non collegate al tracciamento di oggetti irraggiungibili, ai quali nel repository non esistono riferimenti (non sono referenziati da rami o tag). Le informazioni sugli oggetti irraggiungibili sono archiviate in pacchetti separati ("cruft packs"), il che ha reso necessario il loro riflesso negli indici multi-pack MIDX (multi-pack index) per includere oggetti che inizialmente erano irraggiungibili e archiviati solo nel pacchetto cruft, ma che sono diventati raggiungibili dopo un commit che li riferisce.
Nella nuova versione, durante la ripacchettizzazione dei file pack, è garantita la conservazione delle copie aggiuntive degli oggetti raggiungibili, memorizzati solo nei file cruft. Questa modifica garantisce che nel set di file pack, utilizzati per memorizzare gli oggetti raggiungibili, non siano presenti oggetti che fanno riferimento ad altri oggetti memorizzati al di fuori di questo set. Per escludere il contenuto non raggiungibile dai file cruft dagli indici multi-pack (MIDX), è stata proposta un'impostazione chiamata "repack.MIDXMustContainCruft", che consente di ridurre significativamente le dimensioni di tali indici. L'attivazione dell'impostazione nel repository GitHub ha ridotto le dimensioni degli indici MIDX del 38%, accelerato la scrittura negli indici MIDX del 35% e aumentato le prestazioni di lettura del 5%.
- Nel comando "git pack-objects" è stata aggiunta l'opzione "—path-walk", che introduce un nuovo metodo per raccogliere informazioni sugli oggetti durante la ripacchettizzazione dei file pack. Invece di esaminare gli oggetti in base all'ordine delle revisioni, utilizzando la modalità "—path-walk" gli oggetti vengono attraversati tramite il percorso dei file, consentendo di imballare tutti gli oggetti con lo stesso percorso file contemporaneamente. Questo approccio permette di escludere l'euristica che utilizza l'hashing per determinare il legame di un oggetto con il proprio percorso file, oltre a eliminare la necessità di ordinare gli oggetti prima dell'imballaggio. Utilizzando la modalità "—path-walk", le dimensioni dei file pack generati risultano significativamente inferiori rispetto alla raggruppamento degli oggetti tramite hash.
- È stato definito un formato per lo scambio di stati salvati dell'albero di lavoro e degli indici nel repository, creati utilizzando il comando "git stash". Il nuovo formato consente di codificare le modifiche salvate (registrazioni dello stash) come sequenza di commit. Sono state proposte le sottocommande "git stash import" e "git stash export" per importare ed esportare, che possono essere utilizzate per trasferire stati salvati da un sistema all'altro e per eseguire operazioni di push o pull su 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 mostra il contenuto degli oggetti specificati, è stata implementata la possibilità di visualizzare informazioni sugli oggetti mancanti (ad esempio, a causa di un repository danneggiato) e sui sotto-moduli utilizzando le opzioni «—batch» e «—batch-check». In precedenza, specificando il percorso del sotto-modulo, il comando «git cat-file —batch-check» restituiva «missing», mentre ora mostrerà l'identificatore dell'oggetto.
- Nel comando «git log» sono state implementate ottimizzazioni basate sui filtri di Bloom per accelerare la ricerca nella cronologia delle modifiche quando vengono specificati filtri con più percorsi di file, ad esempio, «git log — path/to/a path/to/b».
- I comandi «git switch» e «git restore» sono stati stabilizzati e considerati come sperimentali dal 2019. Questi comandi sono presentati come equivalenti moderni di «git checkout», separando funzionalità poco correlate di quest'ultimo, come la manipolazione dei rami (switch e creazione) e il ripristino dei file nella directory di lavoro.
- È stata dichiarata obsoleta e prevista per la rimozione nel ramo Git 3.0 la comando «git whatchanged», equivalente a «git log —raw».
- Al comando «git for-each-ref» è stata aggiunta l'opzione «—start-after», che può essere usata combinata con l'opzione «—count» per organizzare l'output paginato.
- Ai comandi «git merge» e «git pull» è stata aggiunta l'opzione «—compact-summary» per utilizzare un formato compatto di riepilogo delle modifiche invece del formato diffstat.
- Nella base di codice di Git è stato consentito l'uso della parola chiave «bool», introdotta nello standard C99. Sono state anche documentate alcune funzionalità di C99, utilizzate in modo sperimentale in Git (ad esempio, a metà del 2026 si prevede di consentire l'uso di costrutti come «(struct foo){ .member = value };»). Un compilatore con supporto C99 è obbligatorio per Git dal 2021, ma le caratteristiche della specifica C99 vengono implementate con molta cautela per mantenere la compatibilità con compilatori che supportano solo parzialmente questo standard.
- Sono state apportate modifiche alle regole per l'accettazione delle patch, consentendo l'invio di patch sotto pseudonimo e non solo con il nome reale dello sviluppatore. La modifica è conforme alle regole di accettazione delle patch nel kernel Linux.
- L'elenco degli aggiornamenti di incompatibilità è stato aggiornato con le modifiche che saranno applicate nel ramo Git 3.0. Tra le principali modifiche previste nella prossima versione di Git 3.0, si segnala il passaggio predefinito agli identificatori degli oggetti basati sull'algoritmo di hashing SHA-256 durante l'inizializzazione di nuovi repository e l'utilizzo del formato "reftable" per memorizzare nel repository i riferimenti a rami e tag (utilizzando uno storage a blocchi dal progetto JGit, ottimizzato per la memorizzazione di un numero molto elevato di riferimenti).
Fonte: opennet.ru
