Inspetor de patches e diffs

Como usar

1. Cole um diff unificado na caixa, ou solte sobre ela um arquivo .patch ou .diff.
2. Leia os totais para ver o tamanho da mudança: arquivos tocados, inserções, remoções e número de hunks.
3. Percorra a tabela até os arquivos que interessam; os renomeados mostram o caminho antigo ao lado do novo.
4. Confira o que estiver destacado em âmbar antes de rodar git apply — são os motivos pelos quais ele falharia.
5. Para um patch vindo de e-mail, compare o aviso do hunk com `git apply --check`, que relata a mesma corrupção com menos detalhe.

Perguntas frequentes

O que `corrupt patch at line N` significa de fato?

Significa que o corpo do hunk não continha o número de linhas que seu cabeçalho declarou. Um cabeçalho como @@ -1,4 +1,5 @@ promete quatro linhas do lado antigo (contexto mais remoções) e cinco do novo (contexto mais adições). O git conta enquanto lê e para no instante em que a aritmética quebra, relatando a linha a que chegou e não o cabeçalho que estava errado. Quase sempre a causa é o transporte: um cliente de e-mail requebrou uma linha longa, ou tirou o único espaço inicial que marca uma linha de contexto, e um lado fica curto. Esta ferramenta aponta o hunk, as contagens prometidas e as entregues, o que normalmente basta para corrigir à mão.

Por que linhas de contexto em branco quebram tantos patches?

Porque uma linha de contexto é marcada por um único espaço inicial, então uma linha em branco sem alteração acaba sendo uma linha formada por exatamente um espaço. Isso é invisível, e um bocado de ferramentas o remove: editores que tiram espaços finais ao salvar, clientes de e-mail, aplicativos de chat, copiar e colar através de um terminal. Assim que o espaço some, a linha é lida como vazia em vez de contexto, e o hunk fica uma linha curto dos dois lados. É o jeito mais comum de um patch que parecia certo na tela não aplicar.

Esta ferramenta aplica o patch ou o confere contra meus arquivos?

Não, e não pode. Ela lê o patch em si — a aritmética dentro do diff — sem acesso aos arquivos que ele mira. Isso basta para pegar um patch corrompido ou estragado, que é uma propriedade só do patch. Ela não sabe dizer se as linhas de contexto casam com a sua árvore de trabalho, então um patch que aqui sai bem formado ainda pode ser recusado com `does not apply` se o arquivo tiver seguido em frente. Para essa checagem são necessários os arquivos, e o comando é `git apply --check`.

Ele lê a saída de um `diff -u` comum além de um patch do git?

Sim. Um patch do git acrescenta a linha `diff --git`, a linha index, os metadados de renomeação e modo e — vindo do git format-patch — um cabeçalho de e-mail, e tudo isso é lido quando está presente. Um diff unificado simples do diff -u não tem nada disso: começa direto num par de cabeçalhos `--- ` / `+++ `, e é tratado igual. Renomeações e mudanças de modo simplesmente não podem ser detectadas na forma simples, porque o formato não tem como expressá-las.

Por que a contagem de linhas aqui difere da que o GitHub mostra?

A visão de arquivos do GitHub conta as mesmas linhas, mas o resumo às vezes difere porque ele esconde arquivos gerados, recolhe diffs grandes e exclui binários dos totais. Esta ferramenta conta todos os hunks do patch que você deu, que é o mesmo número que o `git apply --numstat` relata. Se os totais divergirem, verifique se o patch que você tem é a mudança inteira — uma URL .patch de um único commit não vai bater com o diff acumulado de um pull request.

Meu patch é enviado para algum lugar?

Não. O texto é analisado por JavaScript nesta página e nunca enviado a lugar nenhum; o mesmo vale para um arquivo solto, que é lido com a API de arquivos do navegador. Você pode confirmar carregando a página, desconectando-se da rede e colando um diff — continua funcionando. Vale saber, porque um patch costuma ser a coisa mais sensível de uma revisão: contém código não publicado, por inteiro.

Ferramentas relacionadas