Text diff

O `diff` é um dos utilitários mais antigos e essenciais do Unix — foi criado em 1974 por Doug McIlroy nos Bell Labs, o mesmo laboratório que deu origem ao Unix, à linguagem C e ao AWK. A ideia parecia simples: dado dois arquivos de texto, mostrar exatamente o que mudou entre eles. Por baixo, o algoritmo usa LCS (Longest Common Subsequence) para encontrar as linhas em comum e deduzir o que foi adicionado, removido ou modificado. Esse algoritmo tem complexidade O(n*m) no pior caso e foi objeto de refinamentos como o algoritmo de Myers (1986), que é o que o Git usa até hoje.

O diff virou sinônimo de controle de versão. Quando você faz `git diff`, `git log -p` ou revisa um pull request no GitHub, o que você vê é basicamente o formato de saída do `diff` clássico — linhas removidas em vermelho com `-`, linhas adicionadas em verde com `+`, e contexto ao redor para facilitar a localização das mudanças. O código que o Git usa para calcular diffs de texto é fundamentalmente o mesmo algoritmo de 1974, com otimizações. Ferramentas como `vimdiff`, `meld` e `Beyond Compare`, e as visualizações de PR no GitHub e no GitLab existem porque comparar textos versão a versão é uma necessidade central do desenvolvimento de software moderno.

O diff também é extremamente útil fora do código. Comparar dois arquivos de configuração (`.env.example` vs `.env.local`), verificar se um response JSON de uma API mudou entre deploys, conferir se uma migration SQL está igual ao que foi aprovado em review, comparar duas versões de um contrato ou documento legal — todos esses são casos de uso reais de diff no dia a dia de um time de engenharia. Ferramentas de teste de regressão visual como Percy e Chromatic fazem essencialmente um diff de imagens entre versões. O princípio é o mesmo: identificar o que mudou.

Esta ferramenta realiza uma comparação linha a linha entre dois textos que você cola nos painéis esquerdo e direito, destacando visualmente as diferenças. Não é um diff binário nem um diff de três vias (three-way merge como o que o Git usa em conflitos de merge). Para comparações de arquivos maiores com contexto completo e navegação de hunks, use ferramentas dedicadas como `diff` no terminal, `git diff` ou aplicações como `meld`. Para verificações rápidas — conferir se dois JSONs têm a mesma estrutura, comparar saídas de duas chamadas de API, checar mudanças entre rascunhos de texto — esta ferramenta resolve sem instalar nada.

`diff` is one of the oldest and most essential Unix utilities — it was created in 1974 by Doug McIlroy at Bell Labs, the same laboratory that gave birth to Unix, the C language, and AWK. The idea seemed simple: given two text files, show exactly what changed between them. Under the hood, the algorithm uses LCS (Longest Common Subsequence) to find the shared lines and deduce what was added, removed, or modified. That algorithm has O(n*m) complexity in the worst case and was the subject of refinements like the Myers algorithm (1986), which is what Git uses to this day.

`diff` became synonymous with version control. When you run `git diff`, `git log -p`, or review a pull request on GitHub, what you see is essentially the output format of classic `diff` — removed lines in red with `-`, added lines in green with `+`, and surrounding context to help locate the changes. The code Git uses to calculate text diffs is fundamentally the same 1974 algorithm, with optimizations. Tools like `vimdiff`, `meld`, and `Beyond Compare`, and the PR views on GitHub and GitLab exist because comparing text across versions is a core need in modern software development.

`diff` is also enormously useful outside of code. Comparing two configuration files (`.env.example` vs `.env.local`), checking whether a JSON API response changed between deployments, verifying that a SQL migration matches what was approved in review, comparing two versions of a contract or legal document — all of these are real-world diff use cases in an engineering team's daily workflow. Visual regression testing tools like Percy and Chromatic essentially run a diff of images between versions. The principle is the same: identify what changed.

This tool performs a line-by-line comparison between two texts you paste into the left and right panels, visually highlighting the differences. It is not a binary diff or a three-way merge like what Git uses in merge conflicts. For larger file comparisons with full context and hunk navigation, use dedicated tools like `diff` in the terminal, `git diff`, or applications like `meld`. For quick checks — verifying whether two JSONs have the same structure, comparing outputs of two API calls, reviewing changes between text drafts — this tool works without installing anything.

`diff` es una de las utilidades Unix más antiguas y esenciales — fue creada en 1974 por Doug McIlroy en los Bell Labs, el mismo laboratorio que dio origen a Unix, al lenguaje C y a AWK. La idea parecía simple: dados dos archivos de texto, mostrar exactamente qué cambió entre ellos. Por debajo, el algoritmo usa LCS (Longest Common Subsequence) para encontrar las líneas comunes y deducir qué se añadió, eliminó o modificó. Ese algoritmo tiene complejidad O(n*m) en el peor caso y fue objeto de refinamientos como el algoritmo de Myers (1986), que es el que usa Git hasta hoy.

`diff` se convirtió en sinónimo de control de versiones. Cuando ejecutas `git diff`, `git log -p` o revisas un pull request en GitHub, lo que ves es esencialmente el formato de salida del `diff` clásico — líneas eliminadas en rojo con `-`, líneas añadidas en verde con `+`, y contexto circundante para facilitar la localización de los cambios. El código que Git usa para calcular diffs de texto es fundamentalmente el mismo algoritmo de 1974, con optimizaciones. Herramientas como `vimdiff`, `meld` y `Beyond Compare`, y las vistas de PR en GitHub y GitLab existen porque comparar texto entre versiones es una necesidad central en el desarrollo de software moderno.

`diff` también es enormemente útil fuera del código. Comparar dos archivos de configuración (`.env.example` vs `.env.local`), verificar si la respuesta JSON de una API cambió entre despliegues, comprobar que una migración SQL es igual a lo aprobado en revisión, comparar dos versiones de un contrato o documento legal — todos estos son casos de uso reales de diff en el trabajo diario de un equipo de ingeniería. Las herramientas de pruebas de regresión visual como Percy y Chromatic hacen esencialmente un diff de imágenes entre versiones. El principio es el mismo: identificar qué cambió.

Esta herramienta realiza una comparación línea por línea entre dos textos que pegas en los paneles izquierdo y derecho, resaltando visualmente las diferencias. No es un diff binario ni una fusión de tres vías como el que usa Git en conflictos de merge. Para comparaciones de archivos más grandes con contexto completo y navegación por hunks, usa herramientas dedicadas como `diff` en la terminal, `git diff` o aplicaciones como `meld`. Para comprobaciones rápidas — verificar si dos JSONs tienen la misma estructura, comparar salidas de dos llamadas a API, revisar cambios entre borradores de texto — esta herramienta funciona sin instalar nada.