git - パッチ適用時の「1 行で空白エラーが追加されました」とはどういう意味ですか?

Question

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

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

(これは私の Mac で発生しており、元のコードがどこで作成されたのかわかりません。)

警告メッセージは何を意味し、注意する必要がありますか?

Answer 1

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

この警告は、多くのプログラマーが気にしがちなホワイトスペースに関するテキストファイルのクリーン度の基準を定めています。マニュアルで説明されているように：

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

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

したがって、「エラー」は、変更によって末尾の空白、空白のみの行、またはタブの前のスペースが導入されることを意味します。その事実を除けば、変更に誤りはなく、きれいに正しく適用されます。つまり、「間違った」空白を気にしない場合は、警告を無視するか、git config apply.whitespace nowarn.

Answer 2

One case when you could legitimately care is when you want to differentiate between "old" whitespase error (that you might want to keep for legacy reason) and "new" whitespace errors (that you want to avoid).

To that effect, Git 2.5+ (Q2 2015) will propose a more specific option for whitespace detection.

See commits 0e383e1, 0ad782f, and d55ef3e [26 May 2015] by Junio C Hamano (gitster).
^{(Merged by Junio in commit 709cd91, 11 Jun 2015)}

diff.c: --ws-error-highlight=<kind> option

Traditionally, we only cared about whitespace breakages introduced in new lines.
Some people want to paint whitespace breakages on old lines, too. When they see a whitespace breakage on a new line, they can spot the same kind of whitespace breakage on the corresponding old line and want to say "Ah, those breakages are there but they were inherited from the original, so let's not touch them for now."

Introduce --ws-error-highlight=<kind> option, that lets them pass a comma separated list of old, new, and context to specify what lines to highlight whitespace errors on.

The documentation now includes:

--ws-error-highlight=<kind>

Highlight whitespace errors on lines specified by <kind> in the color specified by color.diff.whitespace.
<kind> is a comma separated list of old, new, context.
When this option is not given, only whitespace errors in new lines are highlighted.

E.g. --ws-error-highlight=new,old highlights whitespace errors on both deleted and added lines.
all can be used as a short-hand for old,new,context.

For instance, the old commit had one whitespace error (bbb), but you can focus on the new errors only (at the end of still bbb and ccc):

(test done after t/t4015-diff-whitespace.sh)

---

With Git 2.26 (Q1 2020), the diff-* plumbing family of subcommands now pay attention to the diff.wsErrorHighlight configuration, which has been ignored before; this allows "git add -p" to also show the whitespace problems to the end user.

See commit da80635 (31 Jan 2020) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit df04a31, 14 Feb 2020)}

diff: move diff.wsErrorHighlight to "basic" config

^{Signed-off-by: Jeff King}

We parse diff.wsErrorHighlight in git_diff_ui_config(), meaning that it doesn't take effect for plumbing commands, only for porcelains like git diff itself.
This is mildly annoying as it means scripts like add--interactive, which produce a user-visible diff with color, don't respect the option.

We could teach that script to parse the config and pass it along as --ws-error-highlight to the diff plumbing. But there's a simpler solution.

It should be reasonably safe for plumbing to respect this option, as it only kicks in when color is otherwise enabled. And anybody parsing colorized output must already deal with the fact that color.diff.* may change the exact output they see; those options have been part of git_diff_basic_config() since its inception in 9a1805a872 (add a "basic" diff config callback, 2008-01-04, Git v1.5.4-rc3).

So we can just move it to the "basic" config, which fixes add--interactive, along with any other script in the same boat, with a very low risk of hurting any plumbing users.