「Hunk＃1 FAILED at 1（異なる行末）」メッセージを修正する方法

22

コマンドでパッチを作成しようとしています

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

パッチを適用すると、

$ 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

dos2unixをsrcファイルとパッチファイルの両方に適用しようとしましたが、メッセージは消えません...

UPD：--ignore-whitespaceも役に立たない

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：非常に良い記事が見つかりました：https : //stackoverflow.com/a/4425433/1709408

— user1709408
ソース

試してみてくださいsed -i.bak -e 's/\r$//g' something。dos2unixは、混在した行末をあなたが望むほど積極的に処理するとは思わない。

— -Arthur2e5

完全な悪。あなたはファイルと同じCF-LFの行末、とあなたのパッチを持っている場合、それは最初に喜んであなたのパッチからCRを除去し、その後、（それは行末ことフィット投げるだけで破ったが）一致していませんが。

— SF。

5

patchWindowsのMSYS2に付属のコマンドを使用しても同じ問題が発生しました。私の場合、ソースファイルとパッチの両方にCRLF行末があり、両方をLFに変換することもできませんでした。うまくいったのは次のとおりです。

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

patch パッチが適用されたすべてのファイルで行末をLFに変換するため、CRLFに変換し直す必要があります。

Obs：patch私が使用しているバージョンは2.7.5です

— フェルナンド・コスタ・ベルトルディ
ソース

5

通常、次の-lオプションを使用してこれを回避できます。

-lまたは--ignore-whitespaceオプションを使用します。これにより、パッチは空白文字（つまりスペースとタブ）を緩やかに比較し、パッチファイル内の空でない空白シーケンスが入力ファイル内の空でない空白シーケンスと一致するようにします。

これは標準機能です（POSIXパッチの説明を参照）。

ただし、OP は行末変換が異なるオペレーティングシステム間でgit core.autocrlfでどのように機能するかについてコメントするために質問を修正し、問題がWindows上のファイルで見られることを示唆する例を追加しました（Unixスタイルの例とは対照的に）。ながらpatch試行がCRLFとLF行末の間のミスマッチを収容するために、それは後者が使用されていることを推定するバイアスを有します。パッチファイルの末尾にCRLFがあり、パッチを適用するファイルにはない場合、次のログ例のように回復します。

(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

ソースコードをチェックし、similar関数内でGNU patchは空白をspaceand として扱いTab、行の末尾にLFがあるかどうかに応じて特別な処理を行います。CRは言及されていません。では注意を払っていcheck_line_endingsますが、拒否の診断に役立つメッセージの一部としてのみその情報を使用します。オプションが指定されない限り、pget_lineの末尾のCRを取り除き--binaryます。

GNUパッチには、行末がCRLFであるファイルに適用するために、LFで終わるパッチをCRLFに変換するように指示するオプションがありません。この場合に確実に使用するには、選択肢があります

すべてのファイルを変換してLFエンディングを使用する、または
CRLFの末尾を使用するようにすべてのファイルを変換し、--binaryオプションを追加します。

— トーマス・ディッキー
ソース

5

--ignore-空白（なし秒ダッシュ）私は疑問に更新、あまり助けにはならない

— user1709408

0

Cygwinでも同様の問題がありました。私の場合、修正は-i標準入力から読み取る代わりにフラグを使用することでした。

以下は、異なる行末エラーで失敗しました。

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

しかし、次のことは成功しました。

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

原因は定かではありませんが、誰かが同じ問題を抱えている場合に備えて、ここに残しておきます。

— ジョー
ソース