rilascio del sistema di controllo distribuito delle versioni . Git è uno dei sistemi di controllo delle versioni più popolari, affidabili e ad alte prestazioni, che offre strumenti flessibili per lo sviluppo non lineare, basati su ramificazione e fusione. Per garantire l'integrità della storia e la resistenza alle modifiche retroattive, viene utilizzata la hash implicita dell'intera storia precedente in ogni commit, è inoltre possibile la verifica tramite firme digitali dei tag e dei commit da parte degli sviluppatori.
Rispetto alla versione precedente, nella nuova versione sono stati introdotti 504 cambiamenti, preparati con la partecipazione di 64 sviluppatori, dei quali 12 hanno partecipato per la prima volta allo sviluppo. :
- È stato effettuato il passaggio predefinito a del protocollo di comunicazione Git, utilizzato quando un client si connette a un server Git remoto. La seconda versione del protocollo è nota per offrire la possibilità di filtrare rami e tag dal lato del server, restituendo al client un elenco ridotto di riferimenti. In precedenza, quando eseguiva qualsiasi comando di estrazione, al client veniva sempre inviato l'elenco completo di riferimenti di tutto il repository, anche quando il client aggiornava solo un ramo o verificava l'attualità della propria copia del repository. Un'altra novità significativa è la possibilità di aggiungere nuove funzionalità al protocollo man mano che nuove funzionalità diventano disponibili nel toolkit. Il codice del client rimane compatibile con il vecchio protocollo e può continuare a funzionare sia con i nuovi che con i vecchi server, tornando automaticamente alla prima versione se il server non supporta la seconda.
- Nel comando «git config» è stata aggiunta l'opzione «—show-scope» che semplifica l'identificazione del contesto in cui sono definite determinate impostazioni. Git consente di definire le impostazioni in diverse posizioni: nel repository (.git/info/config), nella cartella dell'utente (~/.gitconfig), nel file di configurazione di sistema (/etc/gitconfig), così come tramite le opzioni della riga di comando e le variabili di ambiente. Quando si esegue «git config», è abbastanza difficile capire dove sia definita esattamente l'impostazione richiesta. Per risolvere questo problema era disponibile l'opzione «—show-origin», ma essa mostra solo il percorso del file in cui è definita l'impostazione, il che è utile se si intende modificare il file, ma non aiuta se è necessario cambiare il valore tramite «git config» utilizzando le opzioni «—system», «—global» o «—local». La nuova opzione «—show-scope» mostra il contesto di definizione delle variabili e può essere utilizzata insieme a «—show-origin»:
$ git —list —show-scope —show-origin
global file:/home/user/.gitconfig diff.interhunkcontext=1
global file:/home/user/.gitconfig push.default=current
[…]
local file:.git/config branch.master.remote=origin
local file:.git/config branch.master.merge=refs/heads/master$ git config —show-scope —get-regexp ‘diff.*’
global diff.statgraphwidth 35
local diff.colormoved plain$ git config —global —unset diff.statgraphwidth
- Nelle impostazioni di associazione è consentito l'uso di wildcard negli URL. Qualsiasi impostazione HTTP e credenziali in Git possono essere definite sia per tutte le connessioni (http.extraHeader, credential.helper), sia per le connessioni associate a URL (credential.https://example.com.helper, credential.https://example.com.helper). Fino ad ora, l'uso di wildcard come *.example.com era consentito solo per le impostazioni HTTP, ma non supportato per l'associazione delle credenziali. In Git 2.26 queste differenze sono state eliminate e ora, ad esempio, è possibile specificare l'associazione di un nome utente a tutti i sottodomini:
[credential «https://*.example.com»]
username = ttaylorr
- È continuata l'espansione del supporto sperimentale per il cloning parziale, che consente di trasferire solo una parte dei dati e lavorare con una copia incompleta del repository. Nella nuova versione è stato aggiunto un nuovo comando «git sparse-checkout add», che consente di aggiungere singole directory per applicare l'operazione «checkout» solo a una parte dell'albero di lavoro, invece di elencare tutte queste directory in una volta tramite il comando «git sparse-checkout set» (è possibile aggiungere una directory alla volta, senza dover ripetere l'intero elenco ogni volta).
Ad esempio, per clonare il repository git/git senza trasferire i blob, limitando la verifica solo alla directory radice della copia di lavoro e con etichette separate per estrarre le directory «t» e «Documentation», si può specificare:$ git clone —filter=blob:none —sparse git@github.com:git/git.git
$ cd git
$ git sparse-checkout init —cone$ git sparse-checkout add t
….
$ git sparse-checkout add Documentation
….
$ git sparse-checkout list
Documentation
t - È stata significativamente aumentata la performance del comando «git grep», utilizzato per cercare sia nel contenuto attuale del repository che nelle revisioni storiche. Per velocizzare la ricerca era consentito scansionare il contenuto dell'albero di lavoro utilizzando più thread («git grep —threads»), ma la ricerca nelle revisioni storiche era monothread. Ora questa limitazione è stata rimossa grazie all'implementazione della possibilità di parallelizzare le operazioni di lettura dallo storage degli oggetti. Per impostazione predefinita, il numero di thread è impostato uguale al numero dei core CPU, il che nella maggior parte dei casi ora non richiede di specificare esplicitamente l'opzione «—threads».
- È stata aggiunta la supporto per il completamento automatico dell'input dei sottocomandi, percorsi, link e altri argomenti del comando «git worktree», permettendo di lavorare con più copie di lavoro del repository.
- È stata aggiunta la supporto per i colori brillanti, per i quali sono presenti sequenze di escape ANSI. Ad esempio, nelle impostazioni dei colori di evidenziazione «git config —color» o «git diff —color-moved» tramite l'opzione «—format» per il blu brillante si può specificare «%C(brightblue)».
- È stata aggiunta una nuova versione dello script , che fornisce integrazione con il meccanismo per accelerare il monitoraggio delle modifiche ai file e la comparsa di nuovi file. Dopo l'aggiornamento di git è necessario hook nel repository.
- Sono state aggiunte ottimizzazioni per velocizzare le operazioni di clonazione parziale (partial clones), relative all'applicazione di bitmap
(bitmap machinery) per evitare di esaminare tutti gli oggetti durante la filtrazione dell'output. La verifica dei blob (—filter=blob:none e —filter=blob:limit=n) durante la clonazione parziale ora avviene
in modo significativamente più veloce. GitHub ha annunciato l'implementazione di patch con queste ottimizzazioni e il supporto sperimentale per la clonazione parziale. - Il comando «git rebase» è stato trasferito su un altro backend che utilizza per impostazione predefinita il meccanismo ‘merge’ (precedentemente usato per «rebase -i») invece di ‘patch+apply’. Ci sono alcune piccole differenze tra i backend, ad esempio, dopo aver ripreso l'operazione dopo la risoluzione di un conflitto (git rebase —continue), il nuovo backend offre la possibilità di modificare il messaggio del commit, mentre il vecchio usava semplicemente il messaggio precedente. Per ripristinare il comportamento precedente, è possibile utilizzare l'opzione «—apply» oppure impostare la variabile di configurazione ‘rebase.backend’ su ‘apply’.
- Un esempio di gestore dei parametri di autenticazione, specificati tramite .netrc, è stato adattato per un utilizzo immediato.
- È stata aggiunta l'impostazione gpg.minTrustLevel per specificare il livello minimo di fiducia per i vari elementi che eseguono il controllo delle firme digitali.
- È stata aggiunta l'opzione «—pathspec-from-file» in «git rm» e «git stash».
- Continua il miglioramento dei set di test in preparazione della transizione all'algoritmo di hashing SHA-2 invece di SHA-1.
Fonte: opennet.ru
