Porque é que reporta uma alteração se os dois textos parecem iguais?

A diferença é provavelmente invisível: espaços no fim da linha, tabs contra espaços, ou uma quebra de linha em falta após a última linha. Ative «ignorar espaços nas margens» para excluir os dois primeiros casos. Uma diferença de quebra de linha final continua a ser reportada — o git também a reporta, com o seu marcador no-newline — porque uma diferença ao nível dos bytes é real mesmo quando nenhum glifo a mostra.

Porque é que textos muito diferentes aparecem como uma única grande substituição?

Encontrar o diff mínimo custa memória proporcional ao quadrado de quão diferentes os textos são. Além de uma distância de edição de cerca de duas mil linhas alteradas, a ferramenta passa a uma vista grosseira de tudo-substituído e mostra um aviso. Com duas versões do mesmo documento nunca lá chegará; comparando dois ficheiros sem relação, sim.

Como aplico o patch copiado?

Guarde-o num ficheiro e execute git apply ficheiro.patch no repositório, ou patch original.txt ficheiro.patch com a ferramenta Unix clássica. O patch foi gerado contra o texto original exato, por isso aplica-se limpo enquanto o destino não tiver mudado.

Algo do meu texto é enviado para algum lado?

Não. A comparação corre inteiramente no seu navegador — não há servidor que possa ver os dois textos. É esse o sentido do cálculo do lado do cliente: configurações, credenciais e dados de produção comparam-se sem sair da sua máquina.

Diff de texto

Compare dois textos lado a lado ou como diff unificado, com realce ao nível da palavra, opções de espaços e maiúsculas e um patch copiável.

Original

Alterado

Ignorar espaços nas margensIgnorar maiúsculas/minúsculas

Resultado

Cole duas versões de um texto para comparar

O que esta ferramenta faz

Um diff responde com precisão a uma única pergunta: o que teria de mudar para transformar um texto noutro? Cole o original no painel «Original» e a versão nova no painel «Alterado», e a ferramenta mostra cada linha eliminada, cada linha adicionada e — dentro de uma linha modificada — as palavras exatas que diferem, realçadas. É a mesma pergunta a que o git responde em cada commit, calculada com a mesma família de algoritmos, inteiramente no seu navegador.

Essa última parte importa mais numa ferramenta de diff do que na maioria: o que as pessoas comparam tende a ser privado — duas versões de uma configuração de produção, uma consulta antes e depois de uma otimização, o corpo de resposta que ontem funcionava contra o que hoje falha. Aqui, nunca saem do seu dispositivo.

Lado a lado ou unificada

As duas vistas mostram a mesma comparação com disposições diferentes. Lado a lado coloca o original e o alterado frente a frente — a coluna do original sob o painel «Original» — com as linhas correspondentes alinhadas: a forma natural de ler a revisão de um documento. Unificada entrelaça-os numa única coluna, eliminações precedidas de um menos e adições de um mais — o formato do git log e das revisões de código, mais compacto e melhor quando as alterações estão dispersas. Ambas as vistas marcam os números de linha originais nas margens, pelo que um achado aqui aponta diretamente para o seu ficheiro.

Como o diff é calculado

A ferramenta implementa o algoritmo de diferenças de Myers, publicado em 1986 e ainda hoje o predefinido do git. Encontra um guião de edição mínimo: o número mínimo de eliminações e inserções de linhas que transforma um texto no outro. Essa minimalidade é o que torna um diff legível — uma comparação ingénua que se ressincroniza mal após uma alteração reporta blocos inteiros como substituídos, enquanto o Myers aponta exatamente as duas linhas que realmente mudaram.

Primeiro comparam-se as linhas, depois cada par de linhas alteradas é comparado de novo ao nível da palavra para produzir os realces. Uma limitação honesta: quando dois textos não têm quase nada em comum, a procura do guião mínimo custaria mais memória do que um separador do navegador deveria gastar; além de uma distância de edição de dois mil, a ferramenta recua para mostrar tudo como substituído — e di-lo com um aviso, em vez de em silêncio.

As opções de espaços e maiúsculas

Muitas diferenças são reais mas irrelevantes. Um ficheiro reindentado de tabs para espaços, um espaço final acrescentado por um editor, uma palavra-chave com outra capitalização — tudo alterações genuínas, tudo ruído quando o que quer saber é se a lógica mudou. As duas caixas cobrem os casos comuns: uma põe de lado os espaços nas margens de cada linha, a outra a diferença de maiúsculas. Afetam apenas o que conta como alteração — a vista mostra sempre cada linha exatamente como foi colada.

Ignorar espaços nas margens — espaços e tabs no início e no fim de cada linha são descartados antes da comparação: uma alteração só de indentação deixa de aparecer como linha modificada. Os espaços dentro da linha continuam a contar.
Ignorar maiúsculas/minúsculas — linhas e palavras que só diferem na capitalização comparam como iguais. Útil para palavras-chave SQL, nomes de cabeçalhos HTTP e outros contextos insensíveis a maiúsculas.

O patch que pode copiar

O botão de copiar produz a comparação em formato unified diff — a língua franca das alterações de código. Cada bloco de alteração (hunk) começa com um cabeçalho @@ que indica os números de linha cobertos, as linhas eliminadas começam com um menos, as adicionadas com um mais, e algumas linhas de contexto inalteradas rodeiam cada bloco para que a alteração possa ser localizada mesmo que o ficheiro tenha deslizado um pouco.

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

Esse texto pode ser colado num ticket ou numa revisão de código, enviado a um colega, ou aplicado mecanicamente: guardado num ficheiro, o git apply ou o comando patch do Unix reproduzirão a alteração sobre o original. Um detalhe que vale a pena conhecer: um ficheiro que não termina com quebra de linha recebe no patch o marcador \ No newline at end of file — a ferramenta reproduz esse comportamento, porque uma quebra de linha final em falta é uma diferença real, e fingir o contrário gera patches que não aplicam.

Perguntas frequentes

Porque é que reporta uma alteração se os dois textos parecem iguais?: A diferença é provavelmente invisível: espaços no fim da linha, tabs contra espaços, ou uma quebra de linha em falta após a última linha. Ative «ignorar espaços nas margens» para excluir os dois primeiros casos. Uma diferença de quebra de linha final continua a ser reportada — o git também a reporta, com o seu marcador no-newline — porque uma diferença ao nível dos bytes é real mesmo quando nenhum glifo a mostra.
Porque é que textos muito diferentes aparecem como uma única grande substituição?: Encontrar o diff mínimo custa memória proporcional ao quadrado de quão diferentes os textos são. Além de uma distância de edição de cerca de duas mil linhas alteradas, a ferramenta passa a uma vista grosseira de tudo-substituído e mostra um aviso. Com duas versões do mesmo documento nunca lá chegará; comparando dois ficheiros sem relação, sim.
Como aplico o patch copiado?: Guarde-o num ficheiro e execute git apply ficheiro.patch no repositório, ou patch original.txt ficheiro.patch com a ferramenta Unix clássica. O patch foi gerado contra o texto original exato, por isso aplica-se limpo enquanto o destino não tiver mudado.
Algo do meu texto é enviado para algum lado?: Não. A comparação corre inteiramente no seu navegador — não há servidor que possa ver os dois textos. É esse o sentido do cálculo do lado do cliente: configurações, credenciais e dados de produção comparam-se sem sair da sua máquina.