Dopo tre mesi di sviluppo, è stato rilasciato Git 2.41, un sistema di gestione dei testi sorgenti distribuiti. Git è uno dei sistemi di gestione delle versioni più popolari, affidabili e ad alte prestazioni, offrendo strumenti flessibili per lo sviluppo non lineare basati su ramificazioni e unioni di branch. Per garantire l'integrità della storia e la resistenza alle modifiche retroattive, viene utilizzata una hash implicita dell'intera storia precedente in ogni commit, ed è possibile anche la certificazione tramite firme digitali degli sviluppatori su singoli tag e commit.
Rispetto alla versione precedente, sono stati introdotti 542 cambiamenti nella nuova versione, realizzati con la partecipazione di 95 sviluppatori, di cui 29 hanno partecipato per la prima volta allo sviluppo. Le principali novità includono:
- Migliorata la gestione degli oggetti irraggiungibili, per i quali non ci sono riferimenti nel repository (branch o tag non puntano su di essi). Gli oggetti irraggiungibili vengono rimossi dal garbage collector, ma prima della rimozione rimangono nel repository per un certo periodo per escludere condizioni di gara. Per monitorare il periodo di permanenza degli oggetti irraggiungibili è necessaria l'associazione di etichette con i timestamp di modifica di tali oggetti, il che non consente di conservarli in un unico file pack, in cui tutti gli oggetti hanno un timestamp comune di modifica. In passato, ogni oggetto irraggiungibile era salvato in un file separato, il che portava a problemi quando c'era un numero elevato di nuovi oggetti irraggiungibili che non erano ancora soggetti a rimozione. Nella nuova versione, per imballare gli oggetti irraggiungibili, viene utilizzato per impostazione predefinita il meccanismo "cruft packs", che consente di memorizzare tutti gli oggetti irraggiungibili in un unico file pack, mentre le informazioni sui timestamp di modifica di ciascun oggetto sono riflettute in una tabella separata, conservata in un file con estensione ".mtimes" e collegata tramite un file indice con estensione ".idx".
- È attivata per impostazione predefinita la gestione dell'indice inverso (revindex) per i file pack. Durante i test nel repository torvalds/linux, l'uso dell'indice inverso ha permesso di accelerare le operazioni ad alta intensità di risorse «git push» di 1,49 volte, mentre operazioni semplici, come il calcolo della dimensione di un singolo oggetto tramite «git cat-file —batch='%(objectsize:disk)'», sono risultate accelerate di 77 volte. I file («.rev») con l'indice inverso verranno salvati all'interno del repository nella directory «.git/objects/pack».
Ricordiamo che Git memorizza tutti i dati sotto forma di oggetti, che sono collocati in singoli file. Per migliorare l'efficienza nel lavoro con il repository, gli oggetti vengono ulteriormente inseriti in file pack, nei quali le informazioni sono presentate come un flusso di oggetti che seguono uno dopo l'altro (un formato analogo è utilizzato quando si trasferiscono oggetti con i comandi git fetch e git push). Per ogni file pack viene creato un file di indice (.idx), che consente di determinare molto rapidamente l'offset nel file pack in cui è memorizzato l'oggetto corrispondente mediante l'ID dell'oggetto.
L'indice inverso incluso nel nuovo rilascio è mirato a ottimizzare il processo di identificazione dell'ID dell'oggetto in base alle informazioni sulla posizione dell'oggetto nel file pack. In precedenza, tale trasformazione veniva eseguita al volo durante l'analisi del file pack e veniva memorizzata solo in memoria, il che non consentiva di riutilizzare tali indici e costringeva a generare l'indice ogni volta. L'operazione di costruzione dell'indice si riduce alla creazione di un array di coppie «oggetto-posizione» e alla sua ordinamento per posizione, il che può richiedere molto tempo per file pack di grandi dimensioni.
Ad esempio, l'operazione di visualizzazione del contenuto degli oggetti, in cui si utilizza l'indice diretto, veniva eseguita 62 volte più velocemente rispetto all'operazione di visualizzazione della dimensione degli oggetti, per la quale i dati sul collegamento della posizione con l'oggetto non erano indicizzati. Dopo l'uso dell'indice inverso, le operazioni indicate hanno iniziato a richiedere all'incirca lo stesso tempo. Gli indici inversi consentono anche di accelerare le operazioni di invio degli oggetti durante l'esecuzione dei comandi fetch e push grazie alla trasmissione diretta dei dati già pronti dal disco.
- Nel protocollo "credential helper", utilizzato per la trasmissione delle credenziali quando si accede a repository con accesso limitato, è stato aggiunto il supporto per la trasmissione degli header WWW-Authenticate tra il gestore delle credenziali e il servizio in cui avviene l'autenticazione. Il supporto dell'header WWW-Authenticate consente di trasmettere i parametri scope dell'OAuth per una separazione più granulare dell'accesso degli utenti ai repository e la delimitazione delle aree accessibili per le richieste.
- Nel comando for-each-ref è stata aggiunta l'opzione di formattazione "%(ahead-behind:)", che consente di ottenere contemporaneamente informazioni sul numero di commit presenti o assenti in un determinato ramo rispetto a un altro ramo (quanto un ramo è indietro o in avanti rispetto a un altro a livello di commit). In precedenza, per ottenere tali informazioni era necessario eseguire due comandi separati: "git rev-list --count main..my-feature" per ottenere il numero di commit unici del ramo e "git rev-list --count my-feature..main" per ottenere il numero di commit assenti. Ora tali calcoli possono essere semplificati in un unico comando, rendendo più facile la scrittura di gestori e riducendo il tempo di esecuzione. Ad esempio, per visualizzare i rami non fusi e valutare la retrocessione o l'anticipo rispetto al loro ramo principale, è possibile utilizzare una singola riga: $ git for-each-ref --no-merged=origin/HEAD \ --format='%(refname:short) %(ahead-behind:origin/HEAD)' \ refs/heads/tb/ | column -t tb/cruft-extra-tips 2 96 tb/for-each-ref--exclude 16 96 tb/roaring-bitmaps 47 3 invece dello script precedentemente utilizzato, che richiedeva 17 volte più tempo: $ git for-each-ref --format='%(refname:short)' --no-merged=origin/HEAD \ refs/heads/tb | while read ref; do ahead="$(git rev-list --count origin/HEAD..$ref)" behind="$(git rev-list --count $ref..origin/HEAD)" printf "%s %d %d\n" "$ref" "$ahead" "$behind" done | column -t tb/cruft-extra-tips 2 96 tb/for-each-ref--exclude 16 96 tb/roaring-bitmaps 47 3
- Nel comando "git fetch" è stata aggiunta l'opzione "--porcelain", che produce un output nel formato " ", meno leggibile ma più comodo per l'analisi in script.
- È stata aggiunta l'impostazione "fetch.hideRefs", che consente di accelerare le operazioni di "git fetch" nascondendo parte dei riferimenti nel repository locale durante la verifica da parte del server dell'intero set di oggetti, il che consente di risparmiare tempo limitando la verifica solo. server, da cui vengono estratti direttamente i dati. Ad esempio, durante un test su un sistema con repository che contengono un grande numero di link esterni monitorati, l'esclusione di tutti i link tranne quelli indirizzati a destinazioni specifiche. server $remote ha permesso di ridurre il tempo di esecuzione dell'operazione «git fetch» da 20 minuti a 30 secondi. $ git -c fetch.hideRefs=refs -c fetch.hideRefs=!refs/remotes/$remote \ fetch $remote
- Nel comando «git fsck» è stata implementata la possibilità di controllare i danneggiamenti, la corrispondenza dei checksum e la correttezza dei valori nelle bitmap di disponibilità e negli indici inversi.
- Nel comando «git clone —local» è stata implementata la visualizzazione di un errore quando si tenta di copiare da un repository che contiene collegamenti simbolici all'interno di $GIT_DIR.
Fonte: opennet.ru
