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


105

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?


Respostas:


126

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.


12
Olhe para o commit com git show- se seu git fizer cores, você verá o ofensivo espaço em branco aparecer em um vermelho raivoso. Além disso, git show --word-diffmostrará não apenas a mudança de linha, mas inserções no meio da linha, o que deve mostrar se o patch realmente adiciona apenas uma palavra no meio ou se também adiciona um espaço em branco à direita.
user4815162342

12
Você não precisa se preocupar. Mas voce devia. Os espaços em branco à direita devem ser erradicados.
funroll de

1
Exceto que o OP não adiciona nenhum novo espaço em branco à direita, apenas modifica o que já existe.
user4815162342

4
Eu vi esse suporte em uma situação semelhante quando as terminações de linha são CRLFs do estilo Windows em vez de Unix.
Ezequiel Muns,

1
@Yarin Se você adicionar uma palavra no meio de uma linha, e a linha já tiver um espaço em branco no final, isso pode acionar o aviso.
Warren Dew

4

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):

velhos e novos erros de shitespace

(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.



-2

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.


1
-1 Você realmente acha que o git reclamaria sobre o recuo da guia no estilo Linus? O único uso legítimo de tab, se houver, é precisamente o início da linha.
user2394284
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.