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
sed -i.bak -e 's/\r$//g' something
. No creo que dos2unix maneje finales de línea mixtos tan agresivamente como desee.Respuestas:
Tuve el mismo problema al usar el
patch
comando 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: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
patch
versión que estoy usando es 2.7.5fuente
Por lo general, puede solucionar esto utilizando la
-l
opción :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
patch
intenta 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:Al verificar el código fuente, en la
similar
función, GNUpatch
trata 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óncheck_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--binary
opció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
--binary
opción.fuente
Tuve un problema similar en Cygwin. En mi caso, la solución fue usar
-i
flag en lugar de leer desde el stdin.Lo siguiente falló con un error de terminación de línea diferente :
Pero lo siguiente tuvo éxito:
No estoy seguro de la causa, pero dejar esto aquí en caso de que alguien tenga el mismo problema.
fuente