¿Cómo arreglar el post "Hunk # 1 FAILED at 1 (different line endings)"?

Estoy tratando de crear un parche con el command

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 file src como al file patch, pero el post no se ha ido …

UPD: –ignore-whitespace no ayuda demasiado

 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: https://stackoverflow.com/a/4425433/1709408

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

use la opción -l o -ignore-white-space, que hace que los parches comparen los caracteres en blanco (es decir, espacios y tabs) de manera que cualquier secuencia no vacía de espacios en blanco en el file de parche coincida con cualquier secuencia no vacía de espacios en blanco en los files de input

Esta pasa a ser una function estándar (consulte la descripción del parche POSIX ).

Sin embargo, OP enmendó la pregunta para comentar cómo las conversiones de finalización de línea funcionan con git core.autocrlf entre diferentes sistemas operativos , y agregó un ejemplo dando a entender que el problema se ve con los files en Windows (en contraste con el ejemplo de estilo Unix). Mientras que el patch intenta acomodar los desajustes entre las terminaciones de línea CRLF y LF, tiene un sesgo para suponer que se usa este último. Si el file del parche tenía terminaciones CRLF, mientras que los files que se iban a parchear no lo hacían, se recuperaría como en este logging 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 

Comprobando el código fuente, en la function similar , el patch GNU trata los espacios en blanco como espacios y Tab , con algún manejo especial según si las líneas tienen un LF final. CR no se menciona. Sí presta atención en check_line_endings , pero usa esa información solo como parte de un post para ayudar a diagnosticar un rechazo. Tiras los CRs finales en pget_line a less que se --binary opción --binary .

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

  • convierta todos los files para usar terminaciones LF, o
  • convierta todos los files para usar terminaciones CRLF y agregue la opción --binary .

Tuve el mismo problema al usar el command de patch que viene con MSYS2 en Windows. En mi caso, tanto el file de origen como el parche tenían un final de línea CRLF, y tampoco funcionó la conversión a LF. 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 files parcheados, por lo que es necesario convertirlos de nuevo a CRLF.

Obs: la versión de patch que estoy usando es 2.7.5