Comment corriger le message «Hunk # 1 FAILED at 1 (different line endings)»?

22

J'essaie de créer un patch avec la commande

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

quand j'applique le patch, ça me donne 

$ 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

J'ai essayé d'appliquer dos2unix au fichier src et au fichier patch, mais le message n'est pas parti ...

UPD: --ignore-whitespace n'aide pas trop

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: a trouvé un très bon article: /programming//a/4425433/1709408

git diff newlines patch user1709408
la source
Essayez sed -i.bak -e 's/\r$//g' something. Je ne pense pas que dos2unix gère les extrémités de lignes mixtes aussi agressivement que vous le souhaitez.
Arthur2e5
Le mal absolu; si vous avez votre patch avec des fins de ligne CF-LF, comme les fichiers, il supprimera d'abord le CR de votre patch, puis jettera un ajustement que les fins de ligne (qu'il vient de casser) ne correspondent pas.
SF.

Réponses:

5

J'ai eu le même problème en utilisant la patchcommande fournie avec MSYS2 sous Windows. Dans mon cas, le fichier source et le correctif avaient une fin de ligne CRLF, et la conversion en LF n'a pas fonctionné non plus. Ce qui a fonctionné était le suivant:

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

patch convertira les fins de ligne en LF sur tous les fichiers corrigés, il est donc nécessaire de les reconvertir en CRLF.

Obs: la patchversion que j'utilise est la 2.7.5

Fernando Costa Bertoldi
la source
5

Vous pouvez généralement contourner ce problème en utilisant l' -loption :

utilisez l'option -l ou --ignore-whitespace, qui permet au patch de comparer les caractères vides (c'est-à-dire les espaces et les tabulations) de manière lâche afin que toute séquence non vide de blancs dans le fichier de patch corresponde à toute séquence non vide de blancs dans les fichiers d'entrée

Il s'agit d'une fonctionnalité standard (voir la description du patch POSIX ).

Cependant, OP a modifié la question pour commenter comment les conversions de fin de ligne fonctionnent avec git core.autocrlf entre différents systèmes d'exploitation , et a ajouté un exemple indiquant que le problème est observé avec les fichiers sous Windows (contrairement à l'exemple de style Unix). Tout en patchessayant de tenir compte des disparités entre les terminaisons de ligne CRLF et LF, il a un biais pour présumer que cette dernière est utilisée. Si le fichier de correctif avait des terminaisons CRLF, alors que les fichiers à corriger n'en avaient pas, il récupérerait comme dans cet exemple de journal:

(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

En vérifiant le code source, dans la similarfonction, GNU patchtraite les espaces comme spaceet Tab, avec une gestion spéciale selon que les lignes ont un LF final. CR n'est pas mentionné. Il fait attention check_line_endings, mais utilise ces informations uniquement dans le cadre d'un message pour aider à diagnostiquer un rejet. Il supprime les CR de fin dans pget_line sauf si l' --binaryoption est donnée.

Le patch GNU n'a pas d'option pour lui dire de transformer un patch avec des terminaisons LF en CRLF à appliquer aux fichiers dont les terminaisons de ligne sont CRLF. Pour l'utiliser de manière fiable dans ce cas, les choix sont

  • convertir tous les fichiers pour utiliser les terminaisons LF, ou
  • convertir tous les fichiers pour utiliser les terminaisons CRLF et ajouter l' --binaryoption.
Thomas Dickey
la source
5
--ignore-whitespace (pas de deuxième tiret) n'aide pas trop, j'ai mis à jour la question
user1709408
0

J'ai eu un problème similaire sur Cygwin. Dans mon cas, le correctif consistait à utiliser -iflag au lieu de lire dans le stdin.

L' erreur suivante a échoué avec une erreur de fin de ligne différente :

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

Mais ce qui suit a réussi:

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

Je ne suis pas sûr de la cause, mais laisser cela ici au cas où quelqu'un aurait le même problème.

Joe
la source