パッチを適用する場合、「1行で空白エラーが追加される」とはどういう意味ですか？

クローンされたリモートリポジトリのいくつかのマークダウンファイルを編集していて、あるブランチから別のブランチへのパッチの作成と適用をテストしたいと思っていました。ただし、変更を加えるたびに、次のメッセージが表示されgit applyます。

0001-b.patch:16: trailing whitespace.
warning: 1 line adds whitespace errors.

（これは私のMacで起こっており、元のコードが作成された場所がわかりません。）

警告メッセージの意味と注意が必要ですか？

あなたは気にする必要はありません。

この警告は、多くのプログラマが気にする傾向がある、空白に関するテキストファイルのクリーン度の標準を制定します。同様にマニュアルは説明しています。

空白エラーと見なされるものは、core.whitespace構成によって制御されます。デフォルトでは、末尾の空白（空白のみで構成される行を含む）および行の最初のインデント内の直後にタブ文字が続く空白文字は、空白エラーと見なされます。

デフォルトでは、コマンドは警告メッセージを出力しますが、パッチを適用します。

したがって、「エラー」とは、変更により末尾の空白、空白のみの行、またはタブの前にスペースが導入されることを意味します。それ以外は、この変更に問題はなく、問題なく正しく適用されます。つまり、「正しくない」空白を気にしない場合は、警告を無視するか、で警告をオフにしてくださいgit config apply.whitespace nowarn。

正当に注意できるケースの1つは、「古い」ホワイトスペースエラー（レガシーの理由で保持したい）と「新しい」ホワイトスペースエラー（回避したい）を区別したい場合です。

そのために、Git 2.5+（2015年第2四半期）は、空白検出のためのより具体的なオプションを提案します。

参照コミット0e383e1、0ad782f、およびd55ef3eによって[2015年5月26日] Junio C浜野を（gitster）。
^{（2015年6月11日、コミット709cd91でJunioによってマージ）}

diff.c： --ws-error-highlight=<kind>オプション

従来、私たちは新しい行で導入された空白の破損のみを気にしていました。
一部の人々も古い行に空白の破損を描きたいと思っています。新しい行に空白の破損が見られる場合、対応する古い行に同じ種類の空白の破損を見つけて、「ああ、それらの破損は元々ありますが、元から継承されているので触れないでください。今。」

紹介--ws-error-highlight=<kind>それらはカンマで区切ったリスト渡すことができますオプション、old、new、とcontext上のハイライト空白のエラーのためにどのような行を指定することを。

ドキュメントが今含まれて：

--ws-error-highlight=<kind>

で指定さ<kind>れた行の空白エラーを、で指定された色で強調表示しますcolor.diff.whitespace。
<kind>のカンマ区切りのリストですold、new、context。
このオプションを指定しないと、new行の空白エラーのみが強調表示されます。

たとえば--ws-error-highlight=new,old、削除された行と追加された行の両方で空白エラーを強調表示します。
allの省略形として使用できますold,new,context。

たとえば、古いコミットには1つの空白エラー（bbb）がありましたが、新しいエラーのみに集中できます（still bbbおよびの最後ccc）。

（テストは後に行われますt/t4015-diff-whitespace.sh）

Git 2.26（2020年第1四半期）では、diff-*サブコマンドの配管ファミリーがdiff.wsErrorHighlight構成に注意を払うようになりました。これは以前は無視されていました。これにより、「git add -p」は空白の問題をエンドユーザーにも表示できます。

Jeff King（）によるcommit da80635（2020年1月31日）を参照してください。^{（合併によりJunio C浜野- -でdf04a31コミット 2020年2月14日）}peff
gitster

diff：diff.wsErrorHighlightを「基本」構成に移動します

^{サインオフ：Jeff King}

でdiff.wsErrorHighlightを解析します。つまり、git_diff_ui_config()配管コマンドでは効果がなく、磁器git diff自体の場合のみ効果があります。
これはadd--interactive、ユーザーに表示される色付きの差分を生成するなどのスクリプトがオプションを尊重しないことを意味するため、少し迷惑です。

このスクリプトで構成を解析--ws-error-highlightし、diff plumb として渡すことを教えることができます。しかし、より簡単な解決策があります。

配管がこのオプションを尊重することは、カラーが他の方法で有効になっている場合にのみ有効になるため、合理的に安全でなければなりません。そして、カラー化された出力を解析する誰color.diff.*もが、彼らが見る正確な出力を変えるかもしれないという事実にすでに対処しなければなりません。これらのオプションはgit_diff_basic_config()、9a1805a872での導入以来一部でした（「基本的な」diff構成コールバック、2008-01-04、Git v1.5.4-rc3を追加します）。

したがって、これを「基本」構成に移動するだけで済みadd--interactiveます。この構成では、同じボート内の他のスクリプトと共にが修正され、配管のユーザーを傷つけるリスクが非常に低くなります。

視覚的な画像での空白エラーは次のとおりです。

http://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines

なぜならTABisteadで始まる行だからですSPACE。パッチファイルに移動して、交換してくださいTABとSPACE。たとえば、vimの行+でパッチファイルタイプxからスペースを削除し、記号+を削除せずに、スペース（CTRL）をeqivに挿入して元のサイズにします。