Dopo tre mesi di sviluppo, è stato presentato il rilascio del sistema distribuito di gestione dei testi sorgente Git 2.52. Git si distingue per le alte prestazioni e offre strumenti per lo sviluppo non lineare, basati sulla ramificazione e sulla fusione dei rami. Per garantire l'integrità della storia e resistere ai cambiamenti retroattivi, viene utilizzata una hash implicita dell'intera storia precedente in ogni commit, oltre alla verifica tramite firme digitali degli sviluppatori di singoli tag e commit. Il codice di Git è distribuito sotto licenza GPLv2+.
Rispetto alla versione precedente, nella nuova versione sono stati inclusi 637 cambiamenti, preparati con la partecipazione di 94 sviluppatori (33 di loro hanno partecipato per la prima volta allo sviluppo di Git). Le principali novità (1, 2, 3):
- È stato aggiunto il comando "git last-modified" per visualizzare l'elenco dei file in una revisione specificata e dei commit attraverso i quali sono state apportate le ultime modifiche a ciascuno di questi file. $ git last-modified HEAD b56f6dcd7b4c90192018e848d0810f091d092913 test.h 29330ae4b820147c98e723399e9438c8bee60a8a test1.c 573ad8917beb99dc643b6e7f5c117a294384a575 test2.c
- È stato aggiunto il comando "git repo" per eseguire operazioni relative all'estrazione di informazioni dal repository. Sono state proposte due sottocomandi: "git repo info" e "git repo structure", che visualizzano informazioni sulle impostazioni del repository e dettagli sulla struttura del repository (ad esempio, puoi scoprire il numero di riferimenti e oggetti nel repository). $ git repo info object.format references.format object.format=sha1 references.format=reftable $ git repo structure | Struttura del repository | Valore | | ——————— | —— | | * Riferimenti | | | * Conteggio | 1983 | | * Rami | 4 | | * Tag | 1125 | | * Remoti | 854 | | * Altri | 0 | | | | | * Oggetti accessibili | | | * Conteggio | 518955 | | * Commit | 77469 | | * Trees | 188865 | | * Blobs | 251631 | | * Tag | 990 |
- Nel comando "git refs" sono stati aggiunti tre sottocomandi che unificano operazioni a basso livello di riferimento sparse e sovrapposte (git for-each-ref, git show-ref, git update-ref e git pack-refs):
- "git refs optimize" — ottimizzazione del backend di memorizzazione dei riferimenti (analogamente a "git pack-refs").
- "git refs list" — visualizzazione dell'elenco di tutti i riferimenti (analogamente a "git for-each-ref" o "git show-ref").
- "git refs exists" — verifica dell'esistenza di un riferimento (equivalente a "git show-ref —exists").
- Il formato per l'esportazione o l'importazione della storia dei commit è stato ampliato con la possibilità di lavorare con firme crittografiche, utilizzando sia identificatori di oggetti basati sull'algoritmo SHA-1, sia su SHA-256. Il comando «git fast-import» ha implementato il supporto per la gestione dei tag firmati in modo simile ai commit firmati. Sono state aggiunte le opzioni «—signed-commits=<modalità>» e «—signed-tags=<modalità>» per controllare la gestione dei commit e dei tag firmati nella fase di importazione (la modalità può assumere valori verbatim, warn-verbatim, warn-stri, strip o abort).
- Nel comando «git maintenance» è stata aggiunta la supporto a una nuova strategia «geometric» («git config set maintenance.strategy geometric»), che consente di ridurre il tempo di mantenimento di grandi monorepository. Rispetto alla strategia precedentemente disponibile, che utilizzava logica simile al comando «git gc», la nuova strategia evita la ricompattazione di tutti gli oggetti ed esclude operazioni eccessivamente dispendiose, come la fusione di tutti i file pack (quando possibile, la fusione avviene a pezzi e senza pulizia degli oggetti rimossi).
- È stato aggiunto il comando «git sparse-checkout clean» per semplificare il ripristino dello stato della directory di lavoro, rimuovendo i file che non corrispondono alla nuova definizione di sparse-checkout, i quali non dovrebbero essere presenti nella copia locale in base alle attuali impostazioni di sparse-checkout.
- Per liberare la base di codice da complicazioni e semplificare la manutenzione, è stata eseguita una refattorizzazione per ridurre l'uso della variabile globale the_repository.
- È stato ampliato l'uso dei filtri di Bloom, una struttura probabilistica per verificare l'appartenenza a un insieme, che ammette false affermazioni di un elemento mancante, ma esclude passi falsi su un elemento esistente. I filtri di Bloom vengono ora utilizzati per accelerare la ricerca nella storia delle modifiche specificando maschere nei percorsi dei file, ad esempio, «foo/bar/*/baz».
- Le prestazioni del comando «git describe» sono aumentate del 30%, grazie all'uso di una coda di priorità. In «git remote rename» sono state accelerate le operazioni di rinominamento dei riferimenti. In «git ls-files» è stato ampliato l'uso degli indici. È stato notevolmente accelerato l'operato del comando «git log -L», grazie all'esclusione di inutili confronti a tre livelli durante l'elaborazione delle fusioni dei commit. Sono state apportate ottimizzazioni alla libreria xdiff.
- È stata fornita un'opzione opzionale per l'utilizzo delle implementazioni in linguaggio Rust di alcune funzioni interne, come la codifica e la decodifica di valori interi a lunghezza variabile. Per impostazione predefinita, il codice Rust non viene utilizzato e richiede l'attivazione del flag di compilazione WITH_RUST. In futuro, ci si aspetta una revisione più significativa di componenti interni di Git in Rust e l'aggiunta di Rust come una delle dipendenze di compilazione obbligatorie in Git 3.0.
- È stata aggiornata la lista delle modifiche che rompono la compatibilità, che verranno applicate nel ramo Git 3.0. In Git 3.0, è stato deciso di cambiare l'impostazione init.defaultBranch del valore predefinito in "main", cioè nei repository creati con il comando "git init", il ramo predefinito si chiamerà "main" e non "master". Si segnala inoltre il passaggio predefinito agli identificatori degli oggetti basati sull'algoritmo di hashing SHA-256 durante l'inizializzazione di nuovi repository. Per semplificare la portabilità tra repository con identificatori di oggetti basati su hash SHA-1 e SHA-256, è stata fornita la possibilità nei repository con un solo algoritmo di hashing di eseguire operazioni di push e pull da un repository che utilizza un altro algoritmo di hashing.
Fonte: opennet.ru
