O que significa “1 linha adiciona erros de espaço em branco” ao aplicar um patch?

Estou editando alguns arquivos markdown de um repositório remoto clonado e queria testar a criação e aplicação de patches de um branch para outro. No entanto, sempre que faço qualquer alteração, recebo a seguinte mensagem durante git apply:

0001-b.patch:16: trailing whitespace.
warning: 1 line adds whitespace errors.

(Isso está acontecendo no meu Mac e não sei onde o código original foi criado.)

O que significa a mensagem de aviso e preciso me preocupar?

Você não precisa se preocupar.

O aviso estabelece um padrão de limpeza de arquivos de texto em relação aos espaços em branco, o tipo de coisa com a qual muitos programadores tendem a se preocupar. Como o manual explica:

O que são considerados erros de espaço em branco é controlado pela configuração core.whitespace. Por padrão, espaços em branco à direita (incluindo linhas que consistem apenas em espaços em branco) e um caractere de espaço que é imediatamente seguido por um caractere de tabulação dentro do recuo inicial da linha são considerados erros de espaço em branco.

Por padrão, o comando emite mensagens de aviso, mas aplica o patch.

Portanto, o "erro" significa que a alteração introduz um espaço em branco à direita, uma linha apenas de espaço em branco ou um espaço que precede uma tabulação. Além desse fato, não há nada de errado com a mudança e ela será aplicada de forma limpa e correta. Em outras palavras, se você não se importa com o espaço em branco "incorreto", fique à vontade para ignorar o aviso ou desligá-lo com git config apply.whitespace nowarn.

Um caso em que você poderia se importar legitimamente é quando deseja diferenciar entre o erro de espaço em branco "antigo" (que você pode querer manter por motivos de legado) e os erros de espaço em branco "novos" (que você deseja evitar).

Para esse efeito, Git 2.5+ (Q2 2015) irá propor uma opção mais específica para a detecção de espaços em branco.

Consulte os commits 0e383e1 , 0ad782f e d55ef3e [26 de maio de 2015] por Junio ​​C Hamano ( gitster) .
^{(Fundido pela Junio no commit 709cd91 , 11 de junho de 2015)}

diff.c: --ws-error-highlight=<kind>opção

Tradicionalmente, nos preocupamos apenas com quebras de espaço em branco introduzidas em novas linhas.
Algumas pessoas também querem pintar quebras de espaço em branco em linhas antigas. Quando eles veem uma quebra de espaço em branco em uma nova linha, eles podem identificar o mesmo tipo de quebra de espaço em branco na linha antiga correspondente e querem dizer "Ah, essas quebras estão lá, mas foram herdadas do original, então não vamos mexer nelas por agora."

Introduzir --ws-error-highlight=<kind>opção, que lhes permite passar uma vírgula lista separada old, newe contextpara especificar quais linhas de destaque espaço em branco erros diante.

A documentação agora inclui :

--ws-error-highlight=<kind>

Realce os erros de espaço em branco nas linhas especificadas por <kind>na cor especificada por color.diff.whitespace.
<kind>é uma lista separada de vírgula old, new, context.
Quando esta opção não é fornecida, apenas os erros de espaço em branco nas newlinhas são destacados.

Por exemplo, --ws-error-highlight=new,olddestaca os erros de espaço em branco nas linhas excluídas e adicionadas.
allpode ser usado como um atalho para old,new,context.

Por exemplo, o commit antigo tinha um erro de espaço em branco ( bbb), mas você pode se concentrar apenas nos novos erros (no final de still bbbe ccc):

(teste feito depois t/t4015-diff-whitespace.sh)

Com o Git 2.26 (Q1 2020), a diff-*família de subcomandos de encanamento agora presta atenção à diff.wsErrorHighlightconfiguração, que foi ignorada antes; isso permite " git add -p" também mostrar os problemas de espaço em branco ao usuário final.

Veja o commit da80635 (31 de janeiro de 2020) de Jeff King ( peff) .
^{(Fundido por Junio ​​C Hamano - gitster- no commit df04a31 , 14 de fevereiro de 2020)}

diff: mova diff.wsErrorHighlight para a configuração "básica"

^{Assinado por: Jeff King}

Analisamos diff.wsErrorHighlight em git_diff_ui_config(), o que significa que ele não tem efeito para comandos de encanamento, apenas para porcelanas como git diffele mesmo.
Isso é um pouco irritante, pois significa que scripts como add--interactive, que produzem um diff visível ao usuário com cores, não respeitam a opção .

Poderíamos ensinar esse script a analisar a configuração e passá-la adiante como --ws-error-highlightpara o encanamento diff. Mas existe uma solução mais simples.

Deve ser razoavelmente seguro para o encanamento respeitar esta opção, já que ela só é ativada quando a cor está ativada de outra forma. E qualquer pessoa que analisa a saída colorida já deve lidar com o fato de que isso color.diff.*pode alterar a saída exata que vê; essas opções fazem parte git_diff_basic_config()desde seu início em 9a1805a872 (adicione um retorno de chamada de configuração diff "básico", 04/01/2008, Git v1.5.4-rc3).

Portanto, podemos apenas movê-lo para a configuração "básica", que corrige add--interactive, junto com qualquer outro script no mesmo barco, com um risco muito baixo de prejudicar qualquer usuário de encanamento.

O erro de espaço em branco com imagens visuais é mostrado aqui.

http://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines

Porque linha começando com TABistead of SPACE. Vá para o arquivo de patch e substitua TABpor SPACE. Por exemplo, no vim on line + do arquivo de patch digite x para remover o espaço e não remover o sinal + e inserir o espaço (CTRL) no eqiv para o tamanho original.