应用补丁程序时，“ 1行会添加空白错误”是什么意思？
Answers:
不用管
该警告针对空白制定了文本文件清洁度的标准，这是许多程序员倾向于关心的事情。如手册所述：
哪些空白错误由core.whitespace配置控制。默认情况下，尾随空格（包括仅由空格组成的行）以及在行的初始缩进内紧随其后是制表符的空格字符都被视为空格错误。
默认情况下，该命令输出警告消息，但会应用补丁程序。
因此，“错误”意味着更改会引入尾随空格，仅空格行或制表符之前的空格。除此之外，更改没有任何错误，它将完全正确地应用。换句话说，如果您不关心“不正确”的空格，请随时忽略该警告或使用关闭它git config apply.whitespace nowarn。
git show-如果您的git有颜色，您将看到冒犯的空白变成愤怒的红色。此外，git show --word-diff不仅会显示行的更改，还会显示行中间的插入，这应显示修补程序是否确实仅在中间添加了单词，或者是否还添加了尾随空格。
您可以合理地关心的一种情况是，您要区分“旧的”空白字符错误（可能由于遗留原因而要保留）和“新的”空白字符错误（您要避免）。
为此，Git 2.5+（2015年第二季度）将为空白检测提出一个更具体的选项。
参见提交0e383e1，0ad782f和d55ef3e [2015年5月25]通过JUNIOÇ滨野（gitster）。
（由Junio在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。
例如，老提交了一个空白的错误（bbb），但你可以专注于新的错误只（在年底still bbb和ccc）：
（测试完成后t/t4015-diff-whitespace.sh）
在Git 2.26（2020年第1季度）中，diff-*管道命令子集现在关注该diff.wsErrorHighlight配置，该配置以前已被忽略；这样git add -p也可以向最终用户显示空白问题。
参见Jeff King（）提交的da80635（2020年1月31日）。（由Junio C Hamano合并--在df04a31提交中，2020年2月14日）peff
gitster
diff：将diff.wsErrorHighlight移至“基本”配置签名人：杰夫·金
我们将diff.wsErrorHighlight解析
git_diff_ui_config()为，这意味着它对管道命令不起作用，仅对像git diff它自己的瓷器有效。
这有点令人讨厌，因为这意味着像脚本这样的脚本add--interactive会产生带有颜色的用户可见差异，而不尊重该选项。我们可以教该脚本来解析配置并将其传递
--ws-error-highlight给diff管道。但是，有一个更简单的解决方案。对于管道而言，尊重该选项应该是相当安全的，因为只有在启用了颜色的情况下，该选项才会生效。并且任何解析彩色输出的人都必须已经处理了
color.diff.*可能改变他们看到的确切输出的事实。git_diff_basic_config()自9a1805a872推出以来，这些选项就已成为其中的一部分（添加了“基本”差异配置回调，2008年1月4日，Git v1.5.4-rc3）。因此，我们可以将其移至“基本”配置，该配置
add--interactive与同一船中的任何其他脚本一起修复，而伤害到任何管道用户的风险非常低。
因为行以TAB代替SPACE。继续打补丁文件并替换TAB为SPACE。例如，从补丁文件类型x的行+上的vim删除空间，而不是删除符号+，并在eqiv上插入空格（CTRL）到原始大小。