Disponibile Git 2.54: nuovo comando "history" e database modulare (aggiornato: 21 aprile 2026, ore 22:34)

A pochi mesi mesi dal rilascio di Git 2.53, il sistema di controllo versione più diffuso al mondo torna con un aggiornamento. Git 2.54 porta un nuovo comando sperimentale per riscrivere la storia dei commit, un cambiamento architetturale profondo nel modo in cui vengono gestiti gli oggetti interni e una serie di migliorie che toccano la vita quotidiana di chi lavora con repository di qualsiasi dimensione. Il rilascio, annunciato dal maintainer Junio Hamano, include contributi di 137 persone, di cui 66 alla prima collaborazione con il progetto. Un segnale di salute per una comunità che resta straordinariamente attiva.

Il nuovo comando git history: riscrivere la storia senza sudore freddo

Chiunque abbia usato git rebase -i per correggere un messaggio di commit o spezzare un commit troppo corposo sa che l'operazione richiede una certa dose di attenzione. Il nuovo comando sperimentale git history nasce per semplificare proprio questi scenari, offrendo un'interfaccia più diretta e meno soggetta a errori.

Per ora sono disponibili due sottocomandi. git history reword [commit] apre l'editor per modificare il messaggio di un commit e aggiorna automaticamente tutti i rami discendenti. git history split [commit] permette di selezionare interattivamente singoli hunk da spostare in un nuovo commit genitore, dividendo di fatto un commit in due. Entrambi operano senza toccare l'albero di lavoro né l'indice - e funzionano persino su repository bare.

Non è un sostituto completo di rebase -i, che resta lo strumento giusto per riorganizzazioni complesse. Per le modifiche puntuali, però - quelle che si fanno più spesso - git history abbassa la soglia di rischio e di complessità in modo significativo. Anche git replay è stato aggiornato per supportarlo.

» Leggi anche: Commit! Pull! Push! - Guida rapida a Git per professionisti impegnati

Object database modulare: un cambiamento che viene da lontano

Sotto la superficie, Git 2.54 segna una tappa importante in un lavoro architetturale iniziato con Git 2.48 nel gennaio 2025: quasi due anni di sviluppo, circa 400 commit confluiti a monte. Il risultato è un object database backend modulare, un'astrazione che consente di sostituire il meccanismo di archiviazione degli oggetti con implementazioni diverse, nello stesso modo in cui i reference backend - files e reftable - sono già intercambiabili.

Il progetto è guidato da Patrick Steinhardt del team Git di GitLab. La copertura non è ancora completa: i flussi di lavoro locali - creare commit, visualizzare il grafo, eseguire merge - funzionano già con il nuovo modello, mentre fetch e push restano esclusi per il momento.

Le implicazioni a medio termine sono tutt'altro che trascurabili. Un object database modulare apre la porta a formati di archiviazione ottimizzati per file binari di grandi dimensioni e a backend personalizzati per piattaforme come GitLab. È il tipo di cambiamento infrastrutturale che non si nota oggi ma che ridefinisce ciò che sarà possibile domani.

Hook definiti nella configurazione

Fino a ieri, gli hook di Git vivevano come script nella directory .git/hooks oppure in un percorso condiviso tramite core.hooksPath.

» Leggi anche: Let's Encrypt con Nginx o Apache: come rinnovare automaticamente il certificato HTTPS e ricaricare il server web dopo il rinnovo

Riutilizzare lo stesso hook su più repository richiedeva soluzioni artigianali. Git 2.54 introduce la possibilità di definire hook direttamente nei file di configurazione, a livello di utente, di sistema o di singolo repository.

La gestione interna degli hook è stata riscritta per supportare questo modello e diversi hook integrati usano già l'API aggiornata. Il vantaggio pratico è immediato: un hook configurato globalmente si applica a tutti i repository dell'utente senza bisogno di symlink o script wrapper, anche per comandi eseguiti al di fuori della directory del repository corrente.

Geometric repacking come strategia predefinita

Il geometric repacking diventa la strategia predefinita per le operazioni di manutenzione manuale (git maintenance run). A differenza del repacking tradizionale, l'approccio geometrico è incrementale: anziché ricompattare l'intero repository ogni volta, aggiorna le strutture dati in modo progressivo. Su repository di grandi dimensioni, dove un repacking completo può richiedere minuti, la differenza si sente.

Staging interattivo e trasporto HTTP più robusti

git add -p riceve miglioramenti alla visibilità degli hunk già accettati o saltati, più una nuova opzione --no-auto-advance che permette di restare sul file corrente dopo l'ultima decisione su un hunk. Dettagli, certo. Ma dettagli che chi usa lo staging interattivo quotidianamente noterà con sollievo.

Sul fronte del trasporto HTTP, Git gestisce ora le risposte HTTP 429 ("Too Many Requests") con un meccanismo di ripetizione automatica anziché trattarle come errori fatali. Il comportamento rispetta l'header Retry-After del server e sono disponibili nuove opzioni di configurazione per numero e tempistica dei tentativi - utile quando si interagisce con servizi che applicano limiti di frequenza aggressivi.

Partial clone e il resto del pacchetto

Il comando sperimentale git backfill accetta ora intervalli di revisione e argomenti pathspec, consentendo di scaricare i blob mancanti per un segmento specifico della storia o per una porzione dell'albero, anziché recuperare tutto a partire da HEAD. Per chi lavora con clone parziali su repository enormi, è un passo avanti concreto nella gestione granulare dei dati.

Tra le altre novità: supporto per nomi di alias non ASCII, miglioramenti a git log -L e a git replay, e un aggiornamento di gitweb - l'interfaccia web integrata di Git - per renderla utilizzabile da dispositivi mobile.

Una nota sul maintainer

Junio Hamano ha annunciato che dopo il rilascio resterà offline per un paio di settimane, senza designare un maintainer ad interim. Per un progetto delle dimensioni e dell'importanza di Git, è un dettaglio che dice molto sulla fragilità strutturale del modello di manutenzione dei grandi progetti open source. Ma questa è una discussione per un'altra volta. Per ora, Git 2.54 è qui ed è un rilascio solido.

Fonti: phoronix.com, linuxiac.com, about.gitlab.com