Diff di testo

Cosa fa questo strumento

Un diff risponde con precisione a una sola domanda: cosa dovrebbe cambiare per trasformare un testo in un altro? Incolla l’originale nel pannello «Originale» e la nuova versione nel pannello «Modificato», e lo strumento mostra ogni riga eliminata, ogni riga aggiunta e — dentro una riga modificata — le parole esatte che differiscono, evidenziate. È la stessa domanda a cui git risponde a ogni commit, calcolata con la stessa famiglia di algoritmi, interamente nel tuo browser.

Quest’ultima parte conta per uno strumento di diff più che per la maggior parte degli altri: ciò che si confronta tende a essere privato — due versioni di una configurazione di produzione, una query prima e dopo un’ottimizzazione, il corpo di risposta che ieri funzionava contro quello che oggi fallisce. Qui non lasciano mai il tuo dispositivo.

Affiancata o unificata

Le due viste mostrano lo stesso confronto disposto in modo diverso. Affiancata mette l’originale e il modificato uno di fronte all’altro — la colonna dell’originale sotto il pannello «Originale» — con le righe corrispondenti allineate: il modo naturale di leggere la revisione di un documento. Unificata li intreccia in un’unica colonna, cancellazioni precedute da un meno e aggiunte da un più — il formato di git log e delle code review, più compatto e migliore quando i cambiamenti sono sparsi. Entrambe le viste riportano i numeri di riga originali nei margini, così un riscontro qui rimanda direttamente al tuo file.

Come viene calcolato il diff

Lo strumento implementa l’algoritmo delle differenze di Myers, pubblicato nel 1986 e ancora oggi il predefinito di git. Trova uno script di modifica minimo: il numero minimo di cancellazioni e inserimenti di righe che trasforma un testo nell’altro. Questa minimalità è ciò che rende leggibile un diff — un confronto ingenuo che si risincronizza male dopo un cambiamento riporta interi blocchi come sostituiti, mentre Myers indica esattamente le due righe che sono davvero cambiate.

Prima si confrontano le righe, poi ogni coppia di righe modificate viene confrontata di nuovo a livello di parola per produrre le evidenziazioni. Un limite dichiarato: quando due testi non hanno quasi nulla in comune, la ricerca dello script minimo costerebbe più memoria di quanta una scheda del browser dovrebbe spendere; oltre una distanza di modifica di duemila lo strumento ripiega quindi sul mostrare tutto come sostituito — e lo dice con un avviso invece che in silenzio.

Le opzioni per spazi e maiuscole

Molte differenze sono reali ma irrilevanti. Un file reindentato da tab a spazi, uno spazio finale aggiunto da un editor, una parola chiave con maiuscole diverse — tutti cambiamenti autentici, tutto rumore quando ciò che vuoi sapere è se la logica è cambiata. Le due caselle coprono i casi comuni: una mette da parte gli spazi ai bordi di ogni riga, l’altra le maiuscole. Influiscono solo su cosa conta come cambiamento — la vista mostra sempre ogni riga esattamente come incollata.

• Ignora spazi ai bordi — spazi e tab all’inizio e alla fine di ogni riga vengono scartati prima del confronto: un cambiamento di sola indentazione smette di apparire come riga modificata. Gli spazi all’interno della riga contano ancora.
• Ignora maiuscole/minuscole — righe e parole che differiscono solo per le maiuscole risultano uguali. Utile per le parole chiave SQL, i nomi degli header HTTP e altri contesti insensibili alle maiuscole.

La patch che puoi copiare

Il pulsante di copia produce il confronto in formato unified diff — la lingua franca dei cambiamenti di codice. Ogni blocco di modifica (hunk) inizia con un’intestazione @@ che indica i numeri di riga coperti, le righe eliminate iniziano con un meno, quelle aggiunte con un più, e alcune righe di contesto invariate circondano ogni blocco così che il cambiamento resti individuabile anche se il file si è leggermente spostato.

--- a
+++ b
@@ -1,3 +1,3 @@
 server:
-  port: 8080
+  port: 9090
   timeout: 30

Questo testo può essere incollato in un ticket o in una code review, inviato a un collega, o applicato meccanicamente: salvato in un file, git apply o il comando patch di Unix ripeteranno il cambiamento sull’originale. Un dettaglio da conoscere: un file che non termina con un a capo riceve nella patch il marcatore \ No newline at end of file — lo strumento riproduce questo comportamento, perché un a capo finale mancante è una differenza reale e fingere il contrario genera patch che non si applicano.