È stato presentato il rilascio del sistema di gestione distribuita dei codici sorgente Git 2.54. Git si distingue per l'alta performance e offre strumenti per lo sviluppo non lineare, basati su ramificazioni e fusioni di rami. Per garantire l'integrità della cronologia e la resistenza alle modifiche retroattive, viene utilizzato l'hashing implicito dell'intera cronologia precedente in ogni commit, insieme alla validazione tramite firme digitali degli sviluppatori per singoli tag e commit. Il codice di Git è distribuito sotto la licenza GPLv2+.
Rispetto alla versione precedente, nella nuova release sono stati inclusi 770 cambiamenti, preparati con la partecipazione di 137 sviluppatori (66 dei quali hanno partecipato per la prima volta allo sviluppo di Git). Principali novità:
- È stato implementato il comando «git history», che fornisce funzionalità sperimentali per la riscrittura della cronologia delle modifiche, più semplici e sicure da utilizzare rispetto al ri-basing dei commit tramite il comando «git rebase». Sono fornite due operazioni:
- «git history reword <commit>» per riscrivere il messaggio di un commit specificato senza modificare l'albero di lavoro e l'indice (salvo le note, il resto rimane intatto). Ad esempio, per correggere un refuso.
- «git history split <commit>» per separare interattivamente il commit specificato in due commit diversi spostando le parti selezionate dal commit originale in un commit aggiuntivo.
Nelle prossime versioni, sono previste l'aggiunta di ulteriori comandi: «git history fixup» per correggere un commit, «git history drop» per eliminare un commit, «git history reorder» per modificare l'ordine dei commit e «git history squash» per unire i commit.
- È stato implementato un nuovo metodo per definire i gestori (hook) nei file di configurazione. Invece di posizionare gli script dei gestori nella cartella «.git/hooks» di ciascun repository, ora è possibile specificare i comandi per invocare i gestori direttamente nei file di configurazione. Le impostazioni possono essere associate a un repository oppure specificate in file di configurazione validi per tutti i repository (/etc/gitconfig) o per i repository dell'utente (~/.gitconfig). È possibile associare più gestori a un singolo evento. Gli script di «.git/hooks» continuano a essere invocati, ma vengono eseguiti dopo i gestori dei file di configurazione. Per visualizzare l'elenco dei gestori è necessario utilizzare il comando «git hook list», mentre per disabilitare selettivamente l'invocazione dei gestori è possibile utilizzare l'impostazione «hook.<name>.enabled = false». [hook «linter»] event = pre-commit command = ~/bin/linter —cpp20 [hook «no-leaks»] event = pre-commit command = ~/bin/leak-detector $ git hook list pre-commit global linter ~/bin/linter —cpp20 local no-leaks ~/bin/leak-detector
- Nel team "git maintenance" è attivata per impostazione predefinita la strategia "geometric" ("git config set maintenance.strategy geometric"), che consente di ridurre i tempi di manutenzione dei grandi monorepository. Rispetto alla strategia precedentemente utilizzata, che si basava su logica simile a quella del team "git gc", la nuova strategia evita il ri-imballaggio di tutti gli oggetti ed esclude operazioni eccessivamente dispendiose in termini di risorse, come la fusione di tutti i file pack (la fusione avviene per parti e senza una pulizia degli oggetti eliminati, quando possibile).
- Il database degli oggetti (ODB) e le API associate sono state migrate verso una nuova architettura basata sull'uso di backend collegabili. La ristrutturazione effettuata astrae il formato di archiviazione degli oggetti e permetterà in futuro di implementare funzionalità come backend e formati alternativi per un'archiviazione più efficace di grandi file binari o per ottimizzare il funzionamento di grandi git hosting.
- Nel comando «git repo structure», che restituisce informazioni sulla struttura del repository, è garantita la visualizzazione non solo della dimensione totale, ma anche dei più grandi oggetti di ogni tipo, il che consente di valutare la dimensione senza l'uso di strumenti esterni come git-sizer. $ git repo structure … | * Oggetti più grandi | | | * Commits | | | * Dimensione massima [1] | 17.23 KiB | | * Genitori massimi [2] | 10 | | * Trees | | | * Dimensione massima [3] | 58.85 KiB | | * Voci massime [4] | 1.18 k | | * Blobs | | | * Dimensione massima [5] | 1019.51 KiB | | * Tag | | | * Dimensione massima [6] | 7.13 KiB |
- Nel comando «git replay», usato invece di «git rebase» per ricreare la storia su server senza albero di lavoro, l'aggiornamento atomico dei riferimenti è impostato per impostazione predefinita (anziché visualizzare un elenco di comandi update-ref da eseguire manualmente), è stata implementata l'opzione «—revert» per annullare le modifiche da una serie di commit, è stata garantita l'eliminazione dei commit vuoti risultanti ed è stata introdotta la possibilità di ricreare la storia fino al commit radice.
- Nel comando «git rev-list» e nei comandi simili è stata aggiunta l'opzione «—maximal-only» per mostrare solo i commit non raggiungibili da altri commit.
- È stata aggiunta l'opzione «—keys» al comando «git repo info» per visualizzare un elenco di tutte le chiavi conosciute.
- Nel comando «git add -p», durante la navigazione tra i blocchi di codice utilizzando i tasti «J» e «K», è stata implementata la marcatura dei blocchi già approvati e saltati. È stata aggiunta l'opzione «—no-auto-advance» per disabilitare il passaggio automatico al file successivo, in modo da poter tornare ai file precedenti prima del commit.
- Ottimizzato l'interfaccia web «gitweb» per il funzionamento su dispositivi mobili.
- Nel comando «git apply —directory» è stata garantita la normalizzazione dei percorsi dei file, come «./un/../normalized/path», prima dell'uso.
- Documentata la possibilità di aggiungere comandi secondari personalizzati posizionando i file «git-» nella directory contenente i file eseguibili.
- Nel comando «git send-email» è stata aggiunta la supporto per certificati client.
- Per il comando «git status» è stata implementata la configurazione «status.compareBranches», tramite la quale è possibile specificare i rami con cui confrontare il ramo attuale. [status] compareBranches = @{upstream} @{push}
- Nel «git rebase» è stata aggiunta l'opzione «—trailer» per semplificare l'aggiunta di metadati a tutti i commit. git rebase —trailer «Reviewed-by: Test »
- È stata aggiunta la possibilità di sostituire le firme per i commit che sono diventate non valide dopo l'importazione nel comando «git fast-import».
- È stata aggiunta la supporto per la compressione (compaction) degli indici a più pacchetti MIDX (multi-pack index), che consente di unire i piccoli strati dell'indice MIDX con informazioni sulla disponibilità degli oggetti e i file bitmap correlati, riducendo così il numero di strati accumulati nei repository esistenti da tempo.
- Nel comando «git backfill» è stata implementata la possibilità di specificare le revisioni (intervalli di commit) e le maschere dei percorsi (pathspec) per limitare le parti della cronologia delle modifiche caricate. git backfill main~100..main git backfill — ‘*.c’
- Sono state aggiunte forme alternative per richiamare il comando «git config list» — «git config -l» e «git config —list».
- È stato consentito l'uso di caratteri non ASCII nei nomi degli alias dei comandi definiti nel file di configurazione. [alias «fetch»] command = fetch
- Modificato il modo in cui vengono visualizzate le firme con chiavi GPG scadute, ma valide al momento della firma del commit. Queste firme ora vengono visualizzate come corrette con una nota sull'inefficacia della chiave (in precedenza venivano evidenziate in rosso, creando l'impressione di essere non valide).
- Quando si accede ai repository tramite HTTP, ora è prevista la gestione dell'errore con codice 429 (Troppe Richieste). Le richieste che terminano con questo errore vengono ora considerate non come un problema fatale, ma come un errore temporaneo, per il quale è necessario ripetere l'operazione dopo un certo intervallo. Il ritardo prima del retry è impostato tramite l'opzione «http.retryAfter», il numero di ripetizioni — «http.maxRetries», e il tempo di attesa — «http.maxRetryTime».
Fonte: opennet.ru
