Dopo due mesi di sviluppo è stato rilasciato il sistema di controllo del codice sorgente distribuito Git 2.39. Git è uno dei sistemi di controllo delle versioni più popolari, affidabili e ad alte prestazioni, che fornisce strumenti di sviluppo flessibili e non lineari basati su branching e merging. Per garantire l’integrità della storia e la resistenza a modifiche retroattive, in ogni commit viene utilizzato l’hashing implicito di tutta la storia precedente; è inoltre possibile certificare i singoli tag e commit con firme digitali degli sviluppatori.
Rispetto alla versione precedente, la nuova versione comprende 483 modifiche, predisposte con la partecipazione di 86 sviluppatori, di cui 31 hanno preso parte allo sviluppo per la prima volta. Principali innovazioni:
- Il comando "git shortlog", destinato a visualizzare riepiloghi con statistiche dalla cronologia delle modifiche, ha aggiunto un'opzione "-group" per il raggruppamento arbitrario di commit per campi non limitati all'autore o al committer. Ad esempio, per visualizzare un elenco di sviluppatori con informazioni sul numero di modifiche, tenendo conto degli helper menzionati nel campo "Coautore", potresti utilizzare il comando: git shortlog -ns --group=author - -group=trailer:co-autore
L'output dello shortlog può essere aggregato utilizzando specificatori di formattazione e l'opzione "--group" può semplificare significativamente la creazione di report complessi ed eliminare la necessità di ulteriori comandi di ordinamento. Ad esempio, per creare un report con informazioni su quanti commit per una determinata versione sono stati accettati in ogni mese, puoi specificare: 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 In precedenza, per eseguire un'operazione simile sarebbe stato necessario utilizzare le utility sort e uniq: git log v2.38.0 .. —date='format:%Y -%m' —format='%cd' | ordinare | unico -c
- Le funzionalità del meccanismo dei "cruft packs", progettato per imballare oggetti irraggiungibili a cui non viene fatto riferimento nel repository (non referenziati da rami o tag), sono state ampliate. Gli oggetti irraggiungibili vengono eliminati dal Garbage Collector, ma rimangono nel repository per un certo periodo prima di essere eliminati per evitare condizioni di competizione. Il meccanismo dei "cruft packs" consente di memorizzare tutti gli oggetti irraggiungibili in un file pack e di visualizzare i dati sull'ora di modifica di ciascun oggetto in una tabella separata, archiviata in un file separato con estensione ".mtimes", in modo che non non sovrapporsi al tempo totale di modifica.
Il periodo di tempo in cui gli oggetti irraggiungibili rimangono nel repository prima che vengano effettivamente eliminati è determinato dall'opzione "—prune=" " Tuttavia, sebbene ritardare l'eliminazione sia un modo abbastanza efficace e pratico per prevenire il danneggiamento del repository a causa delle condizioni di competizione, non è affidabile al 100%. Per facilitare il ripristino di un repository danneggiato, la nuova release offre la possibilità di salvare gli oggetti mancanti aggiungendo l'opzione “--expire-to” al comando “git repack”, che permette di specificare un file per creare un repository esterno copia di tutti gli oggetti eliminati. Ad esempio, per salvare nel file backup.git gli oggetti non raggiungibili che non sono cambiati negli ultimi 5 minuti, è possibile utilizzare il comando: git repack --cruft --cruft-expiration=5.minutes.ago -d --expire -to=../backup.git
- Aumentata significativamente (fino al 70%) la velocità dell'operazione "git grep -cached" durante la ricerca in aree che utilizzano la clonazione parziale (sparse-checkout) e per le quali sono presenti indici parziali (sparse indice). In precedenza, quando si specificava l'opzione "-cached", la ricerca veniva eseguita prima nell'indice normale e poi in quelli parziali, il che portava a notevoli ritardi durante la ricerca in repository di grandi dimensioni.
- È stata accelerata la verifica da parte del server della coerenza dei nuovi oggetti prima che questi vengano inseriti nel repository durante l'operazione "git push". Passando alla contabilizzazione dei soli link dichiarati al momento del controllo, in un repository di test con 7 milioni di link, di cui solo il 3% coperti dall'operazione push, le ottimizzazioni introdotte hanno permesso di ridurre i tempi di controllo di 4.5 volte.
- Per proteggersi da potenziali overflow di numeri interi nel codice, il comando "git apply" limita la dimensione massima delle patch che possono essere elaborate. Se la dimensione della patch supera 1 GB, verrà visualizzato un errore.
- Per proteggersi da potenziali vulnerabilità, sono state apportate modifiche per ripulire le informazioni non necessarie dalle intestazioni impostate quando si utilizza il modulo h2h3 con l'opzione GIT_TRACE_CURL=1 o GIT_CURL_VERBOSE=1 insieme a HTTP/2.
- Quando si esegue un check-out su un ramo che è un collegamento simbolico a un altro ramo, il comando "git simbolico-ref HEAD" ora mostra il nome del ramo di destinazione anziché il nome del collegamento simbolico.
- Aggiunto il supporto per l'argomento @{-1} all'opzione “--edit-description” (“git branch —edit-description @{-1}”) per modificare la descrizione di un ramo precedente.
- Aggiunto il comando "git merge-tree --stdin" per passare un elenco di parametri tramite input standard.
- Sui file system di rete, il gestore fsmonitor, che monitora le modifiche nel file system, è disabilitato per impostazione predefinita.
Fonte: opennet.ru