Dopo due mesi di sviluppo, è stato pubblicato il rilascio del sistema distribuito di controllo delle versioni Git 2.39. Git è uno dei sistemi di versioning 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 la resistenza alle modifiche retroattive, viene utilizzato l'hashing implicito dell'intera cronologia precedente in ogni commit, è anche possibile la verifica tramite firme digitali degli sviluppatori per singoli tag e commit.
Rispetto alla versione precedente, nella nuova versione sono stati inclusi 483 cambiamenti, realizzati con la partecipazione di 86 sviluppatori, di cui 31 hanno partecipato per la prima volta. Le principali novità:
- Nel comando «git shortlog», progettato per visualizzare i riepiloghi delle statistiche dalla cronologia delle modifiche, è stata aggiunta l'opzione «—group» per raggruppare i commit in modo arbitrario per campi che non si limitano all'autore o al committente. Ad esempio, per mostrare un elenco degli sviluppatori con informazioni sul numero di modifiche, considerando i collaboratori menzionati nel campo «Co-authored-by», è possibile utilizzare il comando: git shortlog -ns —group=author —group=trailer:co-authored-by
Вывод shortlog можно агрегировать при помощи спецификаторов форматирования и опция «—group» позволяет существенно упростить создание сложных отчётов и избавиться от выполнении дополнительных команд сортировки. Например, для создания отчёта с информацией о том, сколько коммитов для заданного релиза было принято в каждом месяце, можно указать: git shortlog v2.38.0.. —date=’format:%Y-%m’ —group=’%cd’ -s 2 2022-08 47 2022-09 405 2022-10 194 2022-11 5 2022-12 Раньше для выполнения аналогичной операции потребовалось бы привлечение утилит sort и uniq: git log v2.38.0.. —date=’format:%Y-%m’ —format=’%cd’ | sort | uniq -c
- Le funzionalità del meccanismo "cruft packs" sono state ampliate. Questo strumento serve per l'imballaggio di oggetti irraggiungibili a cui non ci sono riferimenti nel repository (né da rami né da tag). Gli oggetti irraggiungibili vengono rimossi dal garbage collector, ma rimangono nel repository per un certo periodo per prevenire condizioni di gara. Il meccanismo "cruft packs" consente di conservare tutti gli oggetti irraggiungibili in un unico file pack, mentre i dati relativi al momento di modifica di ciascun oggetto vengono registrati in una tabella separata, contenuta in un file con estensione ".mtimes", in modo che non si sovrappongano con il tempo di modifica generale.
Il tempo di permanenza degli oggetti inaccessibili nel repository prima della loro effettiva eliminazione è determinato dall'opzione «—prune=». Sebbene il ritardo prima dell'eliminazione sia un modo piuttosto efficace e pratico per prevenire il danneggiamento del repository a causa di condizioni di race, non è al 100% affidabile. Per semplificare il ripristino di un repository danneggiato, in una nuova release è stata fornita la possibilità di mantenere gli oggetti mancanti, per questo nel comando «git repack» è stata aggiunta l'opzione «—expire-to», 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 inaccessibili 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
- La velocità di esecuzione dell'operazione «git grep —cached» è aumentata significativamente (fino al 70%) nella ricerca in aree in cui viene utilizzato il clone parziale (sparse-checkout) e per le quali sono disponibili indici parziali (sparse index). In precedenza, specificando l'opzione «—cached», si effettuava prima una ricerca nell'indice normale e poi in quelli parziali, causando ritardi significativi nella ricerca in grandi repository.
- Accelerato l'esecuzione su server il controllo di coerenza dei nuovi oggetti prima della loro inclusione nel repository durante l'operazione «git push». Grazie al passaggio a una verifica che considera solo i riferimenti dichiarati, nel repository di test con 7 milioni di riferimenti, di cui solo il 3% coperti dall'operazione push, le ottimizzazioni apportate hanno ridotto il tempo di verifica di 4,5 volte.
- Per proteggere da potenziali overflow interi nel codice, il comando «git apply» ha limitato la dimensione massima dei patch elaborati. Se la dimensione del patch supera 1 GB, ora verrà visualizzato un errore.
- Per proteggere da potenziali vulnerabilità, sono state apportate modifiche per ripulire le informazioni superflue dagli header emessi 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 check out su un ramo che è un riferimento simbolico a un altro ramo, il comando «git symbolic-ref HEAD» ora restituisce il nome del ramo di destinazione, anziché il nome del riferimento simbolico.
- È stato aggiunto il supporto per l'argomento @{-1} nell'opzione «—edit-description» («git branch —edit-description @{-1}») per modificare la descrizione del ramo precedente.
- È stata aggiunta la comando «git merge-tree —stdin», che consente di passare un elenco di parametri tramite lo standard input.
- Sulle filesystem di rete, per impostazione predefinita, il gestore fsmonitor che monitora le modifiche nel filesystem è disattivato.
Fonte: opennet.ru
