Dopo due mesi di sviluppo, Ăš stata pubblicata la versione 2.39 del sistema distribuito di gestione dei testi sorgente Git. Git Ăš uno dei sistemi di controllo versione piĂč popolari, affidabili e performanti, fornendo strumenti flessibili per lo sviluppo non lineare, basati su ramificazione e fusione dei rami. Per garantire l'integritĂ della storia e la resistenza ai cambiamenti retroattivi, viene utilizzato un hashing implicito di tutta la storia precedente in ogni commit, ed Ăš anche possibile la verifica tramite firme digitali dei singoli tag e commit da parte degli sviluppatori.
Rispetto alla versione precedente, la nuova versione accoglie 483 modifiche, preparate con la partecipazione di 86 sviluppatori, dei quali 31 partecipano per la prima volta allo sviluppo. Le novitĂ principali sono:
- Al comando 'git shortlog', progettato per visualizzare i riepiloghi con le statistiche dalla storia delle modifiche, Ăš stata aggiunta l'opzione 'âgroup' per la raggruppamento arbitrario dei commit in base a campi, non limitati all'autore o al committente. Ad esempio, per mostrare l'elenco degli sviluppatori con informazioni sul numero di modifiche, tenendo conto degli assistenti menzionati nel campo 'Co-authored-by', Ăš possibile utilizzare il comando: git shortlog -ns âgroup=author âgroup=trailer:co-authored-by
L'output di shortlog puĂČ essere aggregato utilizzando specificatori di formato e l'opzione "âgroup" consente di semplificare notevolmente la creazione di report complessi, eliminando la necessitĂ di comandi di ordinamento aggiuntivi. Ad esempio, per creare un report con informazioni su quanti commit per una specifica release sono stati accettati in ciascun mese, si puĂČ specificare: git shortlog v2.38.0.. âdate=âformat:%Y-%mâ âgroup=ââ -s 2 2022-08 47 2022-09 405 2022-10 194 2022-11 5 2022-12 In passato, per eseguire un'operazione simile sarebbe stata necessaria l'utilizzo delle utility sort e uniq: git log v2.38.0.. âdate=âformat:%Y-%mâ âformat=ââ | sort | uniq -c
- Sono state ampliate le capacità del meccanismo «cruft packs», progettato per l'imballaggio di oggetti irraggiungibili, sui quali nel repository non sono presenti collegamenti (non referenziati da ramificazioni o tag). Gli oggetti irraggiungibili vengono eliminati dal raccoglitore di spazzatura, ma rimangono nel repository per un certo periodo prima della cancellazione, per escludere stati di gara. Il meccanismo «cruft packs» consente di memorizzare tutti gli oggetti irraggiungibili in un unico file pack, mentre i dati sul tempo di modifica di ciascun oggetto vengono riflessi in una tabella separata, memorizzata in un file distinto con estensione «.mtimes», in modo che non si sovrappongano al tempo di modifica generale.
Il tempo di permanenza degli oggetti irraggiungibili nel repository prima della reale eliminazione Ăš definito dall'opzione «âprune=<date>». Sebbene il ritardo prima della cancellazione sia un modo piuttosto efficace e pratico per prevenire danni al repository a causa di stati di gara, non Ăš al 100% affidabile. Per semplificare il ripristino di un repository danneggiato, nella nuova versione Ăš stata introdotta la possibilitĂ di salvare gli oggetti mancanti: Ăš stata aggiunta l'opzione «âexpire-to» al comando «git repack», che consente di specificare un file per creare una copia esterna di tutti gli oggetti eliminati. Ad esempio, per salvare in un file backup.git gli oggetti irraggiungibili che non sono stati modificati negli ultimi 5 minuti, si puĂČ utilizzare il comando: git repack âcruft âcruft-expiration=5.minutes.ago -d âexpire-to=..\/backup.git
- Ă stata significativamente aumentata (fino al 70%) la velocitĂ di esecuzione dell'operazione «git grep âcached» nella ricerca in aree in cui viene applicato il clone parziale (sparse-checkout) e per le quali sono disponibili indici parziali (sparse index). In precedenza, specificando l'opzione «âcached», si eseguiva prima la ricerca nell'indice normale e poi in quelli parziali, il che portava a ritardi percepibili durante la ricerca in grandi repository.
- Accelerato l'esecuzione su server verifiche di coerenza dei nuovi oggetti prima della loro inclusione nel repository durante l'operazione «git push». Grazie al passaggio a un controllo che considera solo i riferimenti dichiarati, in un repository di prova con 7 milioni di riferimenti, di cui solo il 3% coperti dall'operazione di push, le ottimizzazioni apportate hanno consentito di ridurre il tempo di verifica di 4,5 volte.
- Per proteggere contro potenziali overflow di interi nel codice, il comando «git apply» ha un limite massimo sulla dimensione dei patch elaborati. Se la dimensione del patch supera 1 GB, verrà ora visualizzato un errore.
- Per proteggere contro potenziali vulnerabilitĂ , sono state apportate modifiche per rimuovere informazioni superflue dagli header inviati quando si utilizza il modulo h2h3 con l'opzione GIT_TRACE_CURL=1 o GIT_CURL_VERBOSE=1 insieme a HTTP/2.
- Durante l'operazione di checkout con un ramo che Ú un collegamento simbolico a un altro ramo, il comando «git symbolic-ref HEAD» ora visualizza il nome del ramo di destinazione, e non il nome del collegamento simbolico.
- Ă stata aggiunta la supporto per l'argomento @{-1} nelle opzioni «âedit-description» («git branch âedit-description @{-1}») per modificare la descrizione del ramo precedente.
- Ă stato aggiunto il comando «git merge-tree âstdin», che consente di passare un elenco di parametri tramite standard input.
- Sui filesystem di rete, il gestore fsmonitor, che tiene traccia delle modifiche nel file system, Ăš disabilitato per impostazione predefinita.
Fonte: opennet.ru
