¿Cómo arreglar el mensaje "Hunk # 1 FAILED at 1 (final de línea diferente)"?

22

Estoy tratando de crear un parche con el comando

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

cuando aplico el parche, me da

$ 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

Intenté aplicar dos2unix tanto al archivo src como al archivo de parche, pero el mensaje no desapareció ...

UPD: --ignore-whitespace tampoco ayuda

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: encontré un muy buen artículo: /programming//a/4425433/1709408

— usuario1709408
fuente

Tratar sed -i.bak -e 's/\r$//g' something. No creo que dos2unix maneje finales de línea mixtos tan agresivamente como desee.

— Arthur2e5

El mal absoluto; Si tiene su parche con terminaciones de línea CF-LF, al igual que los archivos, primero eliminará felizmente el CR de su parche, luego se ajustará para que las terminaciones de línea (que simplemente se rompieron) no coincidan.

— SF.

5

Tuve el mismo problema al usar el patchcomando que viene con MSYS2 en Windows. En mi caso, tanto el archivo fuente como el parche tenían un final de línea CRLF, y la conversión de ambos a LF tampoco funcionó. Lo que funcionó fue lo siguiente:

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

patch convertirá los finales de línea a LF en todos los archivos parcheados, por lo que es necesario convertirlos nuevamente a CRLF.

Obs: la patchversión que estoy usando es 2.7.5

— Fernando Costa Bertoldi
fuente

5

Por lo general, puede solucionar esto utilizando la -lopción :

utilice la opción -l o --ignore-whitespace, que hace que el parche compare los caracteres en blanco (es decir, espacios y tabulaciones) sin apretar, de modo que cualquier secuencia de espacios en blanco no vacía coincida con cualquier secuencia de espacios en blanco no vacía en los archivos de entrada

Esta es una característica estándar (consulte la descripción del parche POSIX ).

Sin embargo, OP modificó la pregunta para comentar sobre cómo funcionan las conversiones de final de línea con git core.autocrlf entre diferentes sistemas operativos , y agregó un ejemplo que sugiere que el problema se ve con archivos en Windows (en contraste con el ejemplo de estilo Unix). Si bien patchintenta acomodar las discrepancias entre las terminaciones de línea CRLF y LF, tiene un sesgo para suponer que se utiliza esta última. Si el archivo de parche tuviera terminaciones CRLF, mientras que los archivos a parchar no, se recuperaría como en este registro de ejemplo:

(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

Al verificar el código fuente, en la similarfunción, GNU patchtrata los espacios en blanco como spacey Tab, con un manejo especial de acuerdo a si las líneas tienen un LF final. CR no se menciona. Sí presta atención check_line_endings, pero usa esa información solo como parte de un mensaje para ayudar a diagnosticar un rechazo. Elimina los CR finales en pget_line a menos que se dé la --binaryopción.

El parche GNU no tiene una opción para decirle que transforme un parche con terminaciones LF en CRLF para aplicarlo a archivos cuyas terminaciones de línea son CRLF. Para usarlo de manera confiable para este caso, las opciones son

convertir todos los archivos para usar terminaciones LF, o
convierta todos los archivos para usar terminaciones CRLF y agregue la --binaryopción.

— Thomas Dickey
fuente

55

--ignore-whitespace (sin segundo guión) tampoco ayuda, actualicé la pregunta

— user1709408

0

Tuve un problema similar en Cygwin. En mi caso, la solución fue usar -iflag en lugar de leer desde el stdin.

Lo siguiente falló con un error de terminación de línea diferente :

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

Pero lo siguiente tuvo éxito:

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

No estoy seguro de la causa, pero dejar esto aquí en caso de que alguien tenga el mismo problema.

— Joe
fuente