Como corrigir a mensagem "Hunk # 1 FAILED at 1 (different line endings)"?

22

Estou tentando criar um patch com o comando

git diff sourcefile >/var/lib/laymab/overlay/category/ebuild/files/thepatch.patch

quando aplico o adesivo, isso me dá

$ patch -v
GNU patch 2.7.5

$ /usr/bin/patch -p1 </var/lib/laymab/overlay/category/ebuild/files/thepatch.patch
patching file sourcefile
Hunk #1 FAILED at 1 (different line endings).
Hunk #2 FAILED at 23 (different line endings).
Hunk #3 FAILED at 47 (different line endings).
Hunk #4 FAILED at 65 (different line endings).
Hunk #5 FAILED at 361 (different line endings).
5 out of 5 hunks FAILED -- saving rejects to file sourcefile.rej

Tentei aplicar o dos2unix nos arquivos src e patch, mas a mensagem não foi embora ...

UPD: --ignore-whitespace também não ajuda

PATCH COMMAND:  patch -p1 -g0 -E --no-backup-if-mismatch --ignore-whitespace --dry-run -f < '/var/lib/layman/dotnet/dev-dotnet/slntools/files/remove-wix-project-from-sln-file-v2.patch'

=====================================================
checking file Main/SLNTools.sln
Hunk #1 FAILED at 14 (different line endings).
Hunk #2 FAILED at 49 (different line endings).
Hunk #3 FAILED at 69 (different line endings).
Hunk #4 FAILED at 102 (different line endings).
4 out of 4 hunks FAILED

UPD: encontrou um artigo muito bom: /programming//a/4425433/1709408

— user1709408
fonte

Tente sed -i.bak -e 's/\r$//g' something. Não acho que o dos2unix lida com o final de linhas misto da forma mais agressiva que você desejar.

— Arthur2e5

Absolutamente o mal; se você tiver seu patch com terminações de linha CF-LF, o mesmo que os arquivos, ele primeiro removerá o CR do patch de forma feliz e depois ajustará as terminações de linha (que acabaram de quebrar) não coincidem.

— SF.

5

Eu tive o mesmo problema usando o patchcomando que acompanha o MSYS2 no Windows. No meu caso, o arquivo de origem e o patch tiveram o final da linha CRLF e a conversão de ambos para LF também não funcionou. O que funcionou foi o seguinte:

$ dos2unix patch-file.patch
$ patch -p1 < patch-file.patch
$ unix2dos modified-files...

patch converterá as terminações de linha em LF em todos os arquivos corrigidos, portanto, é necessário convertê-los novamente em CRLF.

Obs: a patchversão que estou usando é 2.7.5

— Fernando Costa Bertoldi
fonte

5

Geralmente, você pode contornar isso usando a -lopção :

use a opção -l ou --ignore-whitespace, que faz com que o patch compare caracteres em branco (ou seja, espaços e tabulações) livremente, para que qualquer sequência não vazia de espaços em branco no arquivo de patch corresponda a qualquer sequência não vazia de espaços em branco nos arquivos de entrada

Esse é um recurso padrão (consulte a descrição do patch POSIX ).

No entanto, o OP alterou a pergunta para comentar sobre como as conversões de final de linha funcionam com o git core.autocrlf entre diferentes sistemas operacionais e adicionou um exemplo sugerindo que o problema é visto nos arquivos no Windows (em contraste com o exemplo no estilo Unix). Embora patchtente acomodar incompatibilidades entre as terminações de linha CRLF e LF, há uma tendência a presumir que o último seja usado. Se o arquivo de correção tivesse terminações de CRLF, enquanto os arquivos a serem corrigidos não, ele se recuperaria como neste exemplo de log:

(Stripping trailing CRs from patch.)
patching file xterm.log.html
(Stripping trailing CRs from patch.)
patching file xterm.man
(Stripping trailing CRs from patch.)
patching file xtermcfg.hin

Verificando o código fonte, na similarfunção, o GNU patchtrata os espaços em branco como spacee Tab, com algum tratamento especial, de acordo com o fato de as linhas terem um LF à direita. CR não é mencionado. Ele presta atenção check_line_endings, mas usa essas informações apenas como parte de uma mensagem para ajudar a diagnosticar uma rejeição. Ele retira os CRs finais em pget_line , a menos que a --binaryopção seja dada.

O patch GNU não tem uma opção para dizer a ele para transformar um patch com terminações LF em CRLF para aplicar a arquivos cujas terminações de linha são CRLF. Para usá-lo de maneira confiável neste caso, as opções são

converter todos os arquivos para usar terminações LF ou
converta todos os arquivos para usar terminações CRLF e adicione a --binaryopção

— Thomas Dickey
fonte

5

--ignore-whitespace (sem segundo traço) também não ajuda, eu atualizei a pergunta

— user1709408

0

Eu tive um problema semelhante no Cygwin. No meu caso, a correção foi usar -iflag em vez de ler no stdin.

O seguinte falhou com erro de final de linha diferente :

patch -t -N -r - -p0 < patchfile

Mas o seguinte foi bem-sucedido:

patch -t -N -r - -p0 -i patchfile

Não tenho certeza da causa, mas deixo isso aqui caso alguém tenha o mesmo problema.

— Joe
fonte