应用补丁时"1行添加空白错误"是什么意思？

Question

我正在编辑克隆的远程存储库的一些markdown文件,并且想要测试从一个分支到另一个分支的创建和应用补丁.但是,每次我进行任何更改时,都会收到以下消息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

您可以合理关心的一种情况是，当您想要区分“旧”空白错误（您可能由于遗留原因而希望保留）和“新”空白错误（您想避免）时。

为此，Git 2.5+（2015 年第 2 季度）将为空白检测提出更具体的选项。

请参阅Junio C Hamano ( )的提交 0e383e1、0ad782f和d55ef3e [2015 年 5 月 26 日] 。^{（由Junio在提交 709cd91中合并，2015 年 6 月 11 日）}gitster

diff.c：--ws-error-highlight=<kind>选项

传统上，我们只关心新行中引入的空格中断。
有些人也想在旧行上绘制空白破损。当他们在新行上看到空格破损时，他们可以在相应的旧行上发现相同类型的空格破损，并想说“啊，那些破损在那里，但它们是从原始行继承的，所以我们不要碰它们”现在。”

引入--ws-error-highlight=<kind>选项，让他们传递逗号分隔的old, new, 和context列表来指定要突出显示空白错误的行。

该文档现在包括：

--ws-error-highlight=<kind>

<kind>以 指定的颜色突出显示 指定的行上的空白错误color.diff.whitespace。是逗号分隔的, ,
<kind>列表。 如果未给出此选项，则仅突出显示行中的空白错误。 oldnewcontext
new

例如，突出--ws-error-highlight=new,old显示已删除和添加的行上的空白错误。
all可以用作 的简写old,new,context。

例如，旧的提交有一个空格错误 ( )，但您可以仅关注新错误（在和 的bbb末尾）：still bbbccc

（测试完成后t/t4015-diff-whitespace.sh）

在 Git 2.26（2020 年第 1 季度）中，diff-*plumbing 系列子命令现在关注配置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差异管道。但有一个更简单的解决方案。

对于管道来说，遵守此选项应该是相当安全的，因为它仅在启用颜色时才会起作用。任何解析彩色输出的人都必须已经处理color.diff.*可能会改变他们看到的确切输出的事实；git_diff_basic_config()这些选项自9a1805a872开始以来一直是其一部分（添加“基本”差异配置回调，2008-01-04，Git v1.5.4-rc3）。

因此，我们可以将其移至“基本”配置，该配置add--interactive与同一条船上的任何其他脚本一起修复，并且伤害任何管道用户的风险非常低。