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 ramificazioni e fusioni. Per garantire l'integrità della cronologia e resistere a modifiche retroattive, viene utilizzato l'hashing implicito dell'intera cronologia precedente in ogni commit, oltre alla possibilità di autentificazione con firme digitali da parte degli sviluppatori per singoli tag e commit.
Rispetto alla versione precedente, questa nuova versione include 504 modifiche, preparate con la partecipazione di 64 sviluppatori, di cui 12 hanno partecipato per la prima volta allo sviluppo. :
- È stata effettuata la transizione predefinita a del protocollo di comunicazione Git, utilizzato quando un client si connette a un server Git remoto. La seconda versione del protocollo è notevole per aver introdotto la possibilità di filtrare rami e tag lato server, restituendo al client un elenco ridotto di riferimenti. In precedenza, quando qualsiasi comando di estrazione veniva eseguito, al client veniva sempre inviato l'intero elenco di riferimenti in tutto il repository, anche quando il client aggiornava solo un ramo o verificava la validità della propria copia del repository. Un'altra innovazione significativa è la possibilità di aggiungere nuove funzionalità al protocollo man mano che nuove funzionalità vengono implementate negli strumenti. Il codice del client rimane compatibile con il vecchio protocollo e può continuare a funzionare sia con i server nuovi che con quelli esistenti, 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'individuazione del contesto in cui sono definite determinate impostazioni. Git consente di definire le impostazioni in diverse posizioni: nel repository (.git/info/config), nella directory dell'utente (~/.gitconfig), nel file di configurazione di sistema (/etc/gitconfig), nonché tramite opzioni della riga di comando e variabili d'ambiente. Quando si esegue "git config" è piuttosto difficile capire dove sia esattamente definita l'impostazione ricercata. Per risolvere questo problema era disponibile l'opzione "—show-origin", che mostra solo il percorso del file in cui è definita l'impostazione, utile se si intende modificare il file, ma non aiuta se si desidera cambiare il valore tramite "git config" utilizzando le opzioni "—system", "—global" o "—local". La nuova opzione "—show-scope" visualizza il contesto in cui sono definite le 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 binding è consentito l'uso di maschere negli URL. Qualsiasi impostazione HTTP e dati di accesso in Git possono essere impostati sia per tutte le connessioni (http.extraHeader, credential.helper) sia per le connessioni associate a un URL (credential.https://example.com.helper, credential.https://example.com.helper). In passato, l'uso di maschere come *.example.com era consentito solo per le impostazioni HTTP, ma non era supportato per l'associazione dei dati di accesso. Con Git 2.26 queste differenze sono state eliminate e, ad esempio, per associare il nome utente a tutti i sottodomini, ora è possibile indicare:
[credential «https://*.example.com»]
username = ttaylorr
- È stata proseguita l'espansione del supporto sperimentale per il cloning parziale (partial clones), che consente di trasferire solo una parte dei dati e lavorare con una copia incompleta del repository. Nella nuova versione è stata aggiunta un nuova 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 le directory simili contemporaneamente tramite il comando "git sparse-checkout set" (è possibile aggiungere una directory per volta, senza dover ridichiarare l'intero elenco ogni volta).
Ad esempio, per clonare il repository git/git senza trasferire blob, limitando la verifica solo alla directory principale della copia di lavoro e con tag separati per il checkout delle directory «t» e «Documentation», puoi 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 - È notevolmente aumentata la performance del comando «git grep», utilizzato per cercare sia nel contenuto attuale del repository che in revisioni storiche. Per accelerare la ricerca era consentito eseguire la scansione del contenuto dell'albero di lavoro con più thread («git grep —threads»), ma la ricerca nelle revisioni storiche era singolo-thread. Ora questa limitazione è stata rimossa grazie all'implementazione della possibilità di parallelizzare le operazioni di lettura dal repository degli oggetti. Per impostazione predefinita, il numero di thread è impostato uguale al numero di core CPU, il che ora, nella maggior parte dei casi, non richiede l'impostazione esplicita dell'opzione «—threads».
- Aggiunta la supporto per il completamento automatico dell'immissione di sottocomandi, percorsi, riferimenti e altri argomenti del comando «git worktree», che consente di lavorare con più copie di lavoro di un repository.
- Aggiunta la supporto per colori brillanti, per i quali sono disponibili 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)».
- Aggiunta una nuova versione dello script , che fornisce integrazione con il meccanismo per accelerare il monitoraggio delle modifiche ai file e della comparsa di nuovi file. Dopo l'aggiornamento di git è necessario il hook nel repository.
- Aggiunte ottimizzazioni per accelerare le operazioni di clonazione parziale (partial clones), relative all'uso di bitmap
(bitmap machinery) per evitare il complete scanning di tutti gli oggetti durante il filtraggio dell'output. Il controllo sui blob (—filter=blob:none e —filter=blob:limit=n) durante la clonazione parziale ora viene effettuato
in modo significativamente più veloce. GitHub ha annunciato l'applicazione di patch con queste ottimizzazioni e il supporto sperimentale per la clonazione parziale. - Il comando «git rebase» è stato spostato su un altro backend che utilizza per default il meccanismo 'merge' (in precedenza usato per 'rebase -i') anziché 'patch+apply'. Ci sono alcune piccole differenze tra i backend; ad esempio, dopo aver continuato l'operazione dopo la risoluzione del conflitto (git rebase --continue), il nuovo backend offre di modificare il messaggio di commit, mentre il vecchio utilizzava semplicemente il messaggio precedente. Per ripristinare il comportamento vecchio, è possibile usare l'opzione '—apply' o impostare la variabile di configurazione 'rebase.backend' su 'apply'.
- Esempio di gestore dei parametri di autenticazione, specificato tramite .netrc, reso utilizzabile immediatamente.
- Aggiunta l'impostazione gpg.minTrustLevel per definire il livello minimo di fiducia per i vari elementi che eseguono la verifica della firma digitale.
- Aggiunta l'opzione '—pathspec-from-file' in 'git rm' e 'git stash'.
- Prosegue il miglioramento dei set di test in preparazione al passaggio all'algoritmo di hashing SHA-2 invece di SHA-1.
Fonte: opennet.ru
