Git 2.54 è disponibile con il nuovo comando git history

A più di due mesi dalla versione 2.53, Git, il sistema di controllo versione distribuito tra i più utilizzati nello sviluppo software, ha rilasciato la versione 2.54.

La novità di punta è il comando sperimentale git history, pensato per semplificare la riscrittura della cronologia. Per ora supporta le operazioni reword e split, che permettono di modificare i messaggi di commit o di spezzare un commit senza dover ricorrere a un rebase interattivo completo.

È un passo avanti concreto: git rebase -i è potente, ma spesso sproporzionato per modifiche banali. Con git history reword si aggiorna il messaggio di commit in modo diretto; con git history split si spostano in modo interattivo le modifiche scelte in un nuovo commit padre. Il comando non tocca né il working tree (la directory di lavoro locale) né l’index (l’area di staging dove si preparano i file prima del commit) e funziona anche sui repository bare (repository senza working tree, usati tipicamente come server remoti).

Un’altra novità rilevante sono gli hook basati sulla configurazione. Fino ad ora gli hook (script che Git esegue automaticamente in risposta a certi eventi, come un commit o un push) erano confinati agli script in .git/hooks o a un core.hooksPath condiviso, il che rendeva scomodo riusarli su più repository. In Git 2.54 gli hook si possono definire direttamente nei file di configurazione, rendendo molto più semplice gestire comportamenti condivisi a livello utente, di sistema o di repository.

Anche la gestione interna degli hook è stata aggiornata per supportare questo modello. Diversi hook nativi usano ora la nuova API, portando i vantaggi della configurazione centralizzata all’intero sistema.

Sul fronte della manutenzione, Git 2.54 adotta il geometric repacking (una strategia che riorganizza i dati del repository in modo incrementale, evitando di ricompattare tutto da zero a ogni esecuzione) come strategia predefinita per le esecuzioni manuali: git maintenance run procede ora in modo più incrementale, riducendo il costo complessivo e mantenendo le strutture dati in ordine.

Non mancano altri miglioramenti. Il flusso interattivo di git add -p mostra ora in modo più chiaro gli hunk (i blocchi di modifiche) già accettati o saltati e introduce l’opzione --no-auto-advance, che mantiene il focus sul file corrente dopo l’ultima decisione. Il trasporto HTTP gestisce ora le risposte 429 “Too Many Requests” ritentando la richiesta invece di andare in errore, rispettando l’header Retry-After del server e offrendo nuove opzioni di configurazione per i tentativi e i relativi intervalli.

Miglioramenti anche per i partial clone (cloni parziali, in cui si scarica solo una parte della cronologia o dei file): il comando sperimentale git backfill accetta ora revision range (intervalli di revisioni, per esempio da un tag a un altro) e argomenti pathspec (filtri che limitano l’operazione a specifici percorsi o file nell’albero), così è possibile recuperare i blob mancanti per una porzione specifica della cronologia o dell’albero, senza scaricare tutto da HEAD.

Completano il quadro il supporto per nomi di alias non-ASCII, alcuni miglioramenti a git log -L e aggiornamenti a git replay, che ora supporta anche il nuovo comando git history. Nel complesso, questa release punta a perfezionare il lavoro quotidiano su scenari d’uso diversi, senza un’unica grande funzionalità che faccia da traino.

Per tutti i dettagli sulle modifiche in Git 2.54, qua l’annuncio ufficiale della release.