Comparar Textos

Cómo se calcula la comparación

Ambos textos se dividen en líneas, y las líneas que tienen en común se hallan como la subsecuencia común más larga, la misma idea sobre la que se construye el comando diff de Unix. Todo lo que está en esa subsecuencia conserva su sitio; lo que queda se indica como eliminado a la izquierda o añadido a la derecha. Cuando una eliminación y una adición quedan contiguas, se emparejan y se muestran como una modificación, no como dos sucesos sin relación.

Cada par modificado recibe después una segunda pasada a nivel de palabra, de modo que en una línea larga con un solo número cambiado se resalta ese número en lugar de poner toda la línea en rojo. Esa es la diferencia entre un diff que se lee y uno que obliga a entornar los ojos, y es la razón por la que las herramientas solo por líneas resultan poco útiles con prosa y archivos de configuración.

Antes de todo eso se recortan las líneas idénticas del principio y del final. Dos archivos de mil líneas que se diferencian en un punto se comparan, por tanto, como un puñado de líneas, lo que es más rápido y más claro.

Cuando dos líneas aparentemente iguales se marcan como distintas

Es la sorpresa más habitual, y la causa siempre es un carácter que no ves. Los espacios al final de la línea son el culpable más frecuente, por eso ignorarlos viene activado por defecto. Después están los finales de línea: un archivo escrito en Windows termina sus líneas con retorno de carro y salto de línea, uno escrito en macOS o Linux solo con salto de línea, y un diff que compare los bytes en bruto dará todas las líneas por modificadas.

Luego vienen los tabuladores frente a series de espacios, que la opción de ignorar espacios unifica; el espacio de no separación que los procesadores de texto y algunas páginas web insertan en lugar de uno normal; las comillas tipográficas y las rayas que introduce la autocorrección; y una marca de orden de bytes (BOM) invisible al principio de la primera línea. Cualquiera de ellos hace que dos líneas idénticas en pantalla sean realmente distintas en el archivo.

El límite de tamaño

La subsecuencia común más larga es cuadrática: comparar m líneas con n líneas llena una tabla de m por n. Con unos cientos de líneas es trivial; con diez mil contra diez mil son cien millones de celdas, y la página dejaría de responder mientras las rellena.

Por eso la comparación tiene un presupuesto de cuatro millones de celdas una vez recortados el prefijo y el sufijo comunes, y una comparación que lo superaría se rechaza con un mensaje en lugar de intentarse. En la práctica, archivos de varios miles de líneas se comparan al instante siempre que se parezcan en general, y solo dos documentos grandes realmente sin relación alcanzan el límite. Cuando ocurre, la herramienta adecuada es un diff de línea de comandos que pueda procesar en flujo.

En paralelo o unificado

La vista en paralelo mantiene cada versión en su propia columna y es mejor para prosa, traducciones y todo aquello en lo que quieres leer ambos textos como textos. La vista unificada los intercala con marcadores, que es el formato de los parches y la revisión de código, y es más fácil de seguir cuando los cambios son pocos y están repartidos por un archivo largo.

Ninguna vista cambia lo que se ha calculado; son dos presentaciones del mismo resultado.

Los algoritmos detrás de un diff

El enfoque clásico, publicado por Eugene Myers en 1986, encuentra el script de edición más corto entre dos secuencias: el conjunto mínimo de inserciones y borrados que convierte una en la otra. Es lo que usan el comando diff de Unix y la implementación por defecto de Git, y es óptimo en el sentido de producir la menor cantidad de cambios.

La menor cantidad de cambios no siempre es lo más legible. Myers puede alinear líneas sin relación que coinciden por casualidad - una llave de cierre aquí, una línea en blanco allá - y producir un diff que entremezcla dos funciones en lugar de mostrar una eliminada y otra agregada. El algoritmo patience de Git aborda esto anclándose en líneas que aparecen exactamente una vez en ambas versiones y aplicando recursión entre esos anclajes, lo que suele coincidir con lo que un lector considera la correspondencia real.

El algoritmo histogram, hoy la alternativa recomendada por Git, extiende patience con una heurística de frecuencia y es más rápido en archivos grandes. Si un diff de revisión de código alguna vez se ve incoherente, poner diff.algorithm en histogram muchas veces produce un resultado más claro a partir exactamente de los mismos dos archivos.

Diferencias entre dos versiones y fusiones a tres bandas

Comparar dos archivos responde qué cambió. Una fusión necesita una tercera entrada - el ancestro común - porque sin ella no hay forma de saber qué lado modificó una línea y cuál simplemente conserva el original. Por eso el control de versiones guarda una base de fusión y por eso las herramientas de fusión a tres bandas muestran tres paneles.

Un conflicto aparece cuando ambos lados cambiaron la misma región respecto de ese ancestro. Todo lo demás se fusiona automáticamente, incluidos los cambios que son adyacentes pero no se superponen, y por eso dos personas pueden editar el mismo archivo todo el día sin conflicto y luego chocar en una sola línea.

Entender esto cambia la forma de resolver conflictos. Los marcadores de un archivo en conflicto muestran tu versión y la del otro, pero la pregunta útil es qué intentaba hacer cada lado respecto de la base, y git checkout --conflict=diff3 agrega la base a los marcadores, lo que suele volver obvia la resolución en vez de dejarla en una adivinanza entre dos alternativas.

Comparar cosas que no son líneas de texto

La comparación por líneas supone que los límites de línea significan algo. El JavaScript minificado, un payload JSON en una sola línea y un párrafo largo de prosa rompen esa suposición: un cambio de un carácter reporta la línea entera como distinta. Formatear ambos lados primero restituye la estructura que el diff necesita, y para JSON una forma canónica - claves ordenadas, sangría consistente - hace que la comparación sea significativa y no accidental.

El CSV tiene el problema opuesto: el diff por líneas funciona, pero reporta un reordenamiento de columnas como un cambio en cada fila. Ordenar primero por una columna clave, o usar una herramienta que entienda CSV, separa el cambio que te interesa del ruido.

Los formatos binarios y casi binarios necesitan sus propios conversores. Un .docx es un zip de XML, un notebook es JSON con la salida incrustada y un PDF es en gran medida opaco. Git admite filtros textconv que convierten un archivo a texto antes de compararlo, y así es como los equipos obtienen diffs legibles de documentos y notebooks sin guardar una segunda copia.

Leer un diff que escribió otra persona

Un diff revisable se define sobre todo por lo que no está en él. El ruido de formato - un formateador pasado sobre el archivo, finales de línea cambiados, un ordenador de imports aplicado - entierra las tres líneas que importan bajo trescientas que no, y el remedio habitual es separar el commit mecánico del sustantivo para que cada uno pueda leerse a su propio ritmo.

Cuando de todos modos te entregan un diff mezclado, la comparación que ignora los espacios en blanco es la vía más rápida: git diff -w, o las opciones para ignorarlos que hay aquí. Vuelve a activarlos antes de aprobar, porque en algunos archivos el espacio en blanco es contenido: la sangría de Python, la estructura de YAML, las tabulaciones de un Makefile y cualquier prueba que verifique la salida exacta.

Los renombrados grandes son el otro caso que conviene atender de manera deliberada. Un archivo movido y editado aparece como un borrado más una adición, salvo que la herramienta detecte el renombrado, y la opción -M de Git o una interfaz de revisión que reconozca renombrados convierte un diff de mil líneas otra vez en las diez líneas que realmente cambiaron.

Comparar textos como tarea editorial

No todo diff es de código. Comparar dos borradores de un contrato, dos traducciones, o un documento antes y después de una edición es un uso frecuente, y la vista en paralelo existe justamente para eso: quieres leer ambos textos como textos, no como un parche.

En prosa, el resaltado a nivel de palabra aporta casi todo el valor, porque una oración reescrita se ve como una oración reescrita y no como una línea borrada y otra agregada. Las herramientas que hacen bien esto dentro de una línea son las que la gente encuentra útiles para el trabajo de edición, y por eso la comparación de aquí ejecuta una segunda pasada a nivel de palabra dentro de cada par de líneas modificadas.

Dos notas prácticas para documentos. El texto pegado desde un procesador de texto suele traer comillas tipográficas, rayas cortas y espacios de no separación que la otra copia no tiene, así que aparecen diferencias donde el texto se ve idéntico. Y un documento exportado dos veces desde la misma fuente puede diferir solo en los saltos de línea, razón por la cual normalizar los finales de línea antes de comparar ahorra mucha confusión.