Vai al contenuto

Test di commit-rewriter 0.1: backup, riscrittura degli hash, limiti e checklist per repository condivisi.

L’ANALISI

commit-rewriter 0.1: ripulire i commit degli agenti senza perdere il rollback

Una web app locale consente di correggere messaggi Git con riferimenti privati o testo generato dagli agenti. Il branch di backup riduce il rischio, ma la riscrittura resta un’operazione da coordinare.

2 min di letturaFatti, limiti e fonti primarie
Interfaccia ufficiale di commit-rewriter per modificare i messaggi Git
Interfaccia ufficiale di commit-rewriter 0.1, eseguita in locale sul repository selezionato.

In breve: commit-rewriter modifica i messaggi senza alterare i file dei commit, crea un branch di backup e aggiorna la catena degli hash dal primo commit corretto. Il test locale Radar ha verificato il percorso su due commit.

Che cosa è stato pubblicato

La release 0.1 distribuisce una web app Python avviabile con uvx o pip. Legge gli ultimi 100 commit del branch main, permette ricerca e modifica multipla e mostra il diff completo prima di applicare le correzioni.

Cosa ha verificato il test Radar

Su un repository temporaneo con due commit, la versione 0.1 ha sostituito il primo messaggio, rigenerato gli hash della catena e conservato il secondo testo. Il processo ha concluso con stato complete e ha creato un branch commit-message-backup con timestamp.

Come protegge la riscrittura

Prima di intervenire il tool controlla che main non sia cambiato, rifiuta repository shallow e operazioni Git in corso, poi crea il riferimento di backup. L’aggiornamento finale usa compare-and-swap per evitare di sovrascrivere un branch modificato nel frattempo.

Cosa cambia davvero nei commit

Il contenuto dei file e gli alberi Git restano invariati, ma ogni commit riscritto riceve un nuovo hash e trascina quelli discendenti. Le firme GPG o mergetag legate agli oggetti precedenti non possono essere conservate e vengono rimosse.

Condizioni e limitazioni

La versione 0.1 opera sul riferimento main e sugli ultimi 100 commit. Non è adatta a una cronologia condivisa senza accordo con i collaboratori; branch remoti, fork e commit firmati richiedono una strategia esplicita di migrazione e verifica.

Checklist pratica

  • Lavorare prima su un clone usa-e-getta e verificare che il branch sia main.
  • Salvare URL remoto, hash corrente e stato di tutti i branch.
  • Correggere soltanto i messaggi necessari e controllare i diff mostrati.
  • Verificare la creazione del branch commit-message-backup.
  • Confrontare alberi e contenuti prima e dopo la riscrittura.
  • Coordinare il force push e la risincronizzazione dei clone condivisi.

Fonti primarie

Radar AI · a cura di Francesco Gruner

Il sito, in una chat.

Servizi, guide e idee da approfondire

Sono l’assistente AI di questo sito. Ti aiuto a orientarti tra il lavoro di Francesco, il blog, Radar AI e i video, con i link alle fonti.

Risposte AI da verificare nelle fonti. 16 messaggi al giorno per rete.