Correggere il messaggio di un vecchio commit in Git, con gli strumenti tradizionali, richiede spesso più passaggi del necessario: rebase interattivo, modifica della todo list, selezione del commit giusto, chiusura del rebase. Funziona, ma è un meccanismo pensato per riscritture più ampie. Nel post dedicato a Git 2.54, GitHub segnala invece un nuovo comando sperimentale, git history, pensato proprio per riscritture mirate; lo stesso articolo raccoglie anche le novità introdotte nella 2.53.

git history: meno attrito per riscritture mirate

Il nuovo comando sperimentale git history nasce per la riscrittura della cronologia in casi circoscritti e, per ora, espone due operazioni: reword e split. La documentazione ufficiale lo presenta esplicitamente come comando sperimentale di history rewriting, non come sostituto generale di git rebase.

// affiliato ▸ Proton VPN · La VPN che non ti spia con sconti fino al 70% · Provala gratis →

git history reword <commit> apre l’editor con il messaggio del commit indicato e ne riscrive il messaggio, lasciando invariato il resto. Per default aggiorna i branch locali che puntano a commit discendenti da quello riscritto; in alternativa può aggiornare solo HEAD. A differenza di git rebase, non tocca né index né worktree, e può operare anche su repository bare.

git history split <commit> consente invece di spezzare un commit in due scegliendo interattivamente quali hunk spostare in un nuovo commit padre. L’interfaccia richiama quella di git add -p, e la documentazione prevede anche la possibilità di limitare l’operazione a un pathspec.

I limiti sono intenzionali. git history non funziona ancora su cronologie che contengono merge e rifiuta operazioni che produrrebbero conflitti. È quindi uno strumento per interventi puntuali e prevedibili, non per riscritture complesse o aperte.

Hook definiti da configurazione

Una delle novità più interessanti di Git 2.54 è la possibilità di definire hook direttamente nei file di configurazione, invece di appoggiarsi solo agli script nel hook directory tradizionale. Questo permette di collocare gli hook nel file utente ~/.gitconfig, in una configurazione di sistema o nella config locale del repository, rendendo molto più semplice condividere gli stessi hook tra più progetti.

Un esempio minimo è questo:

[hook "linter"]
    event = pre-commit
    command = ~/bin/linter

La chiave hook.<nome>.event definisce l’evento che attiva l’hook, mentre hook.<nome>.command indica il comando da eseguire. Si possono anche definire più hook per lo stesso evento; Git li esegue nell’ordine in cui incontra la configurazione. Lo script tradizionale nel hook directory continua comunque a funzionare ed è eseguito per ultimo.

Per vedere quali hook sono attivi conviene essere espliciti anche nel testo: il comando da citare è, per esempio, git hook list pre-commit, non semplicemente git hook list lasciato in sospeso. La manual page documenta infatti list come sottocomando che stampa gli hook relativi a uno specifico evento.

Manutenzione più efficiente di default

Sul fronte della manutenzione, Git 2.54 rende geometric la strategia di default per la manutenzione manuale. In pratica, quando si esegue git maintenance run senza specificare una strategia, Git usa l’approccio geometrico invece del vecchio task gc.

La strategia geometric era stata introdotta in Git 2.52 come opzione esplicita; ora diventa il default per la manutenzione manuale. La documentazione la descrive come sostituto completo della strategia gc e la raccomanda in particolare per repository grandi.

Altre novità

git add -p mostra ora, mentre ci si sposta tra gli hunk con J e K, quali sezioni sono già state accettate o saltate nella sessione corrente. Nello stesso pacchetto di miglioramenti arriva anche --no-auto-advance, che evita il passaggio automatico al file successivo quando si arriva all’ultimo hunk.

git rebase ha inoltre un nuovo parametro --trailer, che aggiunge un trailer a tutti i commit riscritti durante il rebase tramite la machinery di interpret-trailers; l’esempio tipico è una riga come Reviewed-by.

Infine, gli alias non sono più limitati al vecchio set ASCII alfanumerico più trattino. Con la nuova sintassi a sottosezione sono ammessi tutti i caratteri tranne newline e byte NUL, quindi si possono usare anche nomi non latini o con caratteri accentati.

Le note di rilascio complete restano quelle delle versioni 2.53 e 2.54.

La differenza principale rispetto alla tua bozza è che qui ho stretto le formulazioni che potevano essere attaccate, soprattutto su branch aggiornati da git history, sintassi di git hook list e significato preciso del default di git maintenance.