Pourquoi un changement est-il signalé alors que les deux textes semblent identiques ?

La différence est probablement invisible : espaces en fin de ligne, tabulations contre espaces, ou saut de ligne manquant après la dernière ligne. Activez « ignorer les espaces de bord » pour écarter les deux premiers cas. Une différence de saut de ligne final reste signalée — git la signale aussi, avec son marqueur no-newline — parce qu’une différence au niveau des octets est réelle même quand aucun glyphe ne la montre.

Pourquoi des textes très différents s’affichent-ils comme un seul grand remplacement ?

Trouver le diff minimal coûte une mémoire proportionnelle au carré de la différence entre les textes. Au-delà d’une distance d’édition d’environ deux mille lignes changées, l’outil bascule vers une vue grossière tout-remplacé et affiche un avertissement. Avec deux versions du même document vous ne l’atteindrez jamais ; en comparant deux fichiers sans rapport, si.

Comment appliquer le correctif copié ?

Enregistrez-le dans un fichier, puis lancez git apply fichier.patch dans le dépôt, ou patch original.txt fichier.patch avec l’outil Unix classique. Le correctif a été généré contre le texte original exact : il s’applique proprement tant que la cible n’a pas dérivé.

Une partie de mon texte est-elle envoyée quelque part ?

Non. La comparaison s’exécute entièrement dans votre navigateur — aucun serveur ne peut voir les deux textes. C’est tout l’intérêt du calcul côté client : configurations, identifiants et données de production se comparent sans quitter votre machine.

Comparateur de textes

Comparez deux textes côte à côte ou en diff unifié, avec surlignage au niveau des mots, options d’espaces et de casse, et un correctif copiable.

Original

Modifié

Ignorer les espaces de bordIgnorer la casse

Résultat

Collez deux versions d’un texte à comparer

Ce que fait cet outil

Un diff répond précisément à une seule question : que faudrait-il changer pour transformer un texte en un autre ? Collez l’original dans le panneau « Original » et la nouvelle version dans le panneau « Modifié », et l’outil montre chaque ligne supprimée, chaque ligne ajoutée et — dans une ligne modifiée — les mots exacts qui diffèrent, surlignés. C’est la même question à laquelle git répond à chaque commit, calculée avec la même famille d’algorithmes, entièrement dans votre navigateur.

Cette dernière partie compte plus pour un outil de diff que pour la plupart des autres : ce que l’on compare tend à être privé — deux versions d’une configuration de production, une requête avant et après optimisation, le corps de réponse qui marchait hier face à celui qui échoue aujourd’hui. Ici, ils ne quittent jamais votre appareil.

Côte à côte ou unifiée

Les deux vues montrent la même comparaison, disposée différemment. Côte à côte place l’original et le modifié face à face — la colonne de l’original sous le panneau « Original » — avec les lignes correspondantes alignées : la façon naturelle de lire la révision d’un document. Unifiée les entrelace en une seule colonne, suppressions précédées d’un moins et ajouts d’un plus — le format de git log et des revues de code, plus compact et meilleur quand les changements sont épars. Les deux vues indiquent les numéros de ligne d’origine dans les marges, si bien qu’une trouvaille ici renvoie directement à votre fichier.

Comment le diff est calculé

L’outil implémente l’algorithme de différences de Myers, publié en 1986 et toujours celui de git par défaut aujourd’hui. Il trouve un script d’édition minimal : le nombre minimal de suppressions et d’insertions de lignes qui transforme un texte en l’autre. Cette minimalité est ce qui rend un diff lisible — une comparaison naïve qui se resynchronise mal après un changement rapporte des blocs entiers comme remplacés, là où Myers pointe exactement les deux lignes qui ont réellement bougé.

Les lignes sont comparées d’abord, puis chaque paire de lignes modifiées est comparée à nouveau au niveau des mots pour produire les surlignages. Une limite assumée : quand deux textes n’ont presque rien en commun, la recherche du script minimal coûterait plus de mémoire qu’un onglet de navigateur ne devrait en dépenser ; au-delà d’une distance d’édition de deux mille, l’outil retombe donc sur un affichage tout-remplacé — et le dit par un avertissement plutôt qu’en silence.

Les options d’espaces et de casse

Beaucoup de différences sont réelles mais sans intérêt. Un fichier réindenté des tabulations vers les espaces, une espace finale ajoutée par un éditeur, un mot-clé recapitalisé — autant de changements authentiques, autant de bruit quand ce que vous voulez savoir est si la logique a changé. Les deux cases couvrent les cas courants : l’une écarte les espaces aux bords de chaque ligne, l’autre écarte la casse. Elles n’affectent que ce qui compte comme changement — l’affichage montre toujours chaque ligne exactement telle que collée.

Ignorer les espaces de bord — les espaces et tabulations en début et fin de ligne sont écartés avant la comparaison : un changement d’indentation seul cesse d’apparaître comme ligne modifiée. Les espaces à l’intérieur d’une ligne comptent toujours.
Ignorer la casse — les lignes et les mots qui ne diffèrent que par les majuscules sont considérés comme égaux. Utile pour les mots-clés SQL, les noms d’en-têtes HTTP et les autres contextes insensibles à la casse.

Le correctif que vous pouvez copier

Le bouton de copie produit la comparaison au format diff unifié — la lingua franca des changements de code. Chaque bloc de changement (hunk) commence par un en-tête @@ qui nomme les numéros de ligne couverts, les lignes supprimées commencent par un moins, les ajoutées par un plus, et quelques lignes de contexte inchangées entourent chaque bloc pour situer le changement même si le fichier a légèrement bougé.

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

Ce texte peut être collé dans un ticket ou une revue de code, envoyé à un collègue, ou appliqué mécaniquement : enregistré dans un fichier, git apply ou la commande patch d’Unix rejoueront le changement sur l’original. Un détail à connaître : un fichier qui ne se termine pas par un saut de ligne reçoit dans son correctif le marqueur \ No newline at end of file — l’outil reproduit ce comportement, car un saut de ligne final manquant est une vraie différence, et prétendre le contraire produit des correctifs qui ne s’appliquent pas.

Questions fréquentes

Pourquoi un changement est-il signalé alors que les deux textes semblent identiques ?: La différence est probablement invisible : espaces en fin de ligne, tabulations contre espaces, ou saut de ligne manquant après la dernière ligne. Activez « ignorer les espaces de bord » pour écarter les deux premiers cas. Une différence de saut de ligne final reste signalée — git la signale aussi, avec son marqueur no-newline — parce qu’une différence au niveau des octets est réelle même quand aucun glyphe ne la montre.
Pourquoi des textes très différents s’affichent-ils comme un seul grand remplacement ?: Trouver le diff minimal coûte une mémoire proportionnelle au carré de la différence entre les textes. Au-delà d’une distance d’édition d’environ deux mille lignes changées, l’outil bascule vers une vue grossière tout-remplacé et affiche un avertissement. Avec deux versions du même document vous ne l’atteindrez jamais ; en comparant deux fichiers sans rapport, si.
Comment appliquer le correctif copié ?: Enregistrez-le dans un fichier, puis lancez git apply fichier.patch dans le dépôt, ou patch original.txt fichier.patch avec l’outil Unix classique. Le correctif a été généré contre le texte original exact : il s’applique proprement tant que la cible n’a pas dérivé.
Une partie de mon texte est-elle envoyée quelque part ?: Non. La comparaison s’exécute entièrement dans votre navigateur — aucun serveur ne peut voir les deux textes. C’est tout l’intérêt du calcul côté client : configurations, identifiants et données de production se comparent sans quitter votre machine.