Dos textos que parecen idénticos rara vez lo son, y encontrar la diferencia a ojo es una tarea en la que los humanos son espectacularmente malos. Esta herramienta compara línea a línea y marca qué se añadió y qué se quitó. Lo interesante es que "qué ha cambiado" es una pregunta con más de una respuesta correcta.
La diferencia invisible que hace que todo parezca cambiado
Si un diff informa de que todas y cada una de las líneas han cambiado mientras el texto claramente no, la respuesta son casi siempre los finales de línea. Windows termina las líneas con un retorno de carro más un salto de línea; Unix, Linux y macOS usan solo el salto. Ninguno de los dos se ve en pantalla.
El efecto es total. Divide "uno\ndue\ntre" y "uno\r\ndue\r\ntre" en líneas y obtienes ["uno","due","tre"] frente a ["uno\r","due\r","tre\r"]: cada línea lleva ahora un pasajero invisible, y solo la última, sin salto final, coincide. Una de cada tres. Los textos son iguales; los bytes no.
Por eso git tiene ajustes autocrlf y por eso los equipos discuten sobre ellos. Si comparas el archivo de un compañero en Windows con el tuyo en un Mac, normaliza los finales antes de buscar significado en el resultado.
No existe un único diff correcto
Esto sorprende a quien da por hecho que un diff es un hecho. No lo es: es una respuesta entre varias igualmente mínimas. Si se borra una línea de una racha de líneas idénticas, nada en el texto dice cuál desapareció. El algoritmo elige, y algoritmos distintos eligen distinto.
Añade una función a un archivo fuente y el diff puede mostrar tu función nueva como añadida, o puede mostrar tu llave de cierre como añadida y la de la función siguiente como quitada: ambos son mínimos, uno solo es comprensible. Por eso justamente git trae varios algoritmos: el predeterminado Myers es rápido, mientras que patience e histogram producen diffs que encajan mejor con cómo un humano ve el cambio. Ninguno es más correcto. Optimizan definiciones distintas de buena respuesta.
Por qué las comparaciones grandes chocan contra un muro
El algoritmo clásico construye una tabla de cada línea de A contra cada línea de B, lo que cuesta tiempo y memoria proporcionales al producto de ambas longitudes. Dos archivos de 12.000 líneas necesitan una tabla de 144 millones de celdas: más de un gigabyte de memoria y casi dos segundos de trabajo. En un móvil, eso es una pestaña muerta.
La salvación es que las comparaciones reales rara vez son aleatorias. Dos versiones de un documento suelen compartir una larga cabecera y una larga cola idénticas, y esas líneas no necesitan tabla alguna: son iguales a simple vista. Quitarlas primero es el primer movimiento de toda implementación seria de diff, y en dos archivos de 12.000 líneas que difieren en un sitio lleva la tabla de 144 millones de celdas a un puñado.
Eso cubre el caso normal. No ayuda cuando dos textos grandes son genuinamente distintos de principio a fin, porque entonces no hay cabecera ni cola común que quitar. Esta herramienta traza ahí una raya y te lo dice, en vez de intentarlo y morir: si tras el recorte la comparación es demasiado grande, recibes un mensaje. Es una elección deliberada: una herramienta que te congela el navegador es peor que una que admite sus límites.
Las líneas son la granularidad equivocada para la prosa
Esta herramienta compara líneas enteras, lo que va bien para código, configuración y cualquier cosa donde una línea sea una unidad con sentido. Va mal para la prosa. Cambia una palabra en un párrafo que vive en una sola línea y el diff marcará el párrafo entero como quitado y vuelto a añadir: técnicamente cierto y prácticamente inútil.
El remedio en esa situación es trabajar con texto de una frase por línea, o recurrir a un diff a nivel de palabra. Conviene saber cuál estás mirando: un diff de líneas sobre un documento con ajuste de línea te dice que un párrafo cambió, y nada sobre qué cambió dentro.
Preguntas frecuentes
¿Se envía mi texto a un servidor?
No. Esta herramienta está marcada como "client": ambos textos se comparan en la pestaña de tu navegador y ninguno sale de tu máquina. Aquí importa más de lo habitual, porque comparar dos versiones de algo significa que tienes dos versiones: contratos, borradores, archivos de configuración con credenciales dentro.
¿Por qué dice que todas las líneas han cambiado si parecen iguales?
Los finales de línea, casi con seguridad: mira arriba. El otro candidato son los espacios al final, igual de invisibles e igual de fatales para una comparación. Si tu editor puede mostrar los caracteres invisibles, actívalo y mira el final de las líneas.
¿Por qué hay una línea vacía de más al final?
Porque el texto termina con un salto de línea. Dividir "a\nb\n" por saltos da tres piezas: "a", "b" y una cadena vacía tras el último salto. No es un fallo del diff; es lo que significa un salto final. La convención Unix dice que los archivos de texto deberían terminar con uno, así que es muy común y normalmente no merece la pena perseguirlo.
¿Puede comparar dos archivos en vez de texto pegado?
Aquí no: esta es una herramienta de pegar. Para archivos, y en particular para cualquier cosa bajo control de versiones, usa git diff: maneja los finales de línea, ofrece los mejores algoritmos mencionados arriba, y puede mostrar cambios a nivel de palabra dentro de una línea. Esta herramienta es para la comparación rápida donde abrir un terminal es más esfuerzo del que merece la pregunta.
¿Ignora los espacios en blanco?
No. Cada carácter cuenta, incluidos los espacios finales y la indentación. Es el valor por defecto correcto para una herramienta general —a veces el espacio en blanco es justo el cambio que buscas— pero significa que un archivo reindentado saldrá como completamente reescrito. Si esa es tu situación, git diff -w ignora los espacios y te enseña lo que de verdad se movió.