クローン化されたリモートリポジトリのマークダウンファイルを編集しており、あるブランチから別のブランチへのパッチの作成と適用をテストしたかった。ただし、変更を加えるたびに、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四半期)では、空白検出のためのより具体的なオプションを提案します。
commits 0e383e1 、 ad782f 、および d55ef3e [2015年5月26日] by Junio C Hamano(gitster
) 。
( Junio in commit 709cd91 、2015年6月11日)
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
の後に行われます)
視覚的な画像のホワイトスペースエラーを次に示します。
http://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines