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

What does "1 line adds whitespace errors" mean when applying a patch?

提问by Yarin

I'm editing some markdown files of a cloned remote repository, and wanted to test creating and applying patches from one branch to another. However, every time I make any change at all, I get the following message during git apply:

我正在编辑克隆的远程存储库的一些降价文件，并想测试从一个分支到另一个分支的创建和应用补丁。但是，每次我进行任何更改时，都会收到以下消息git apply：

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

(This is happening on my Mac, and I don't know where the original code was created.)

（这发生在我的 Mac 上，我不知道原始代码是在哪里创建的。）

What does the warning message mean, and do I need to care?

警告消息是什么意思，我需要关心吗？

回答by user4815162342

You don't need to care.

你不需要关心。

The warning enacts a standard of cleanliness of text files in regard to whitespace, the kind of thing that many programmers tend to care about. As the manualexplains:

该警告制定了关于空格的文本文件清洁标准，这是许多程序员倾向于关心的事情。正如手册解释的那样：

What are considered whitespace errors is controlled by core.whitespace configuration. By default, trailing whitespaces (including lines that solely consist of whitespaces) and a space character that is immediately followed by a tab character inside the initial indent of the line are considered whitespace errors.

By default, the command outputs warning messages but applies the patch.

什么被认为是空白错误是由 core.whitespace 配置控制的。默认情况下，尾随空格（包括仅由空格组成的行）和在行的初始缩进内紧跟一个制表符的空格字符被视为空格错误。

默认情况下，该命令会输出警告消息但会应用补丁。

So, the "error" means that the change introduces a trailing whitespace, a whitespace-only line, or a space that precedes a tab. Other than that fact, there is nothing erroneous about the change, and it will apply cleanly and correctly. In other words, if you don't care about the "incorrect" whitespace, feel free to ignore the warning or turn it off with git config apply.whitespace nowarn.

因此，“错误”意味着更改引入了尾随空格、纯空格行或制表符前面的空格。除此之外，更改没有任何错误，它将干净且正确地应用。换句话说，如果您不关心“不正确”的空格，请随意忽略警告或使用git config apply.whitespace nowarn.

回答by VonC

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.

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

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

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

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 contextto specify what lines to highlight whitespace errors on.

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

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

介绍--ws-error-highlight=<kind>选项，让他们通过一个逗号分隔的列表old，new以及context对指定哪些线来突出空白错误。

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 newlines are highlighted.

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

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

例如--ws-error-highlight=new,old，在已删除和添加的行上突出显示空白错误。
all可以用作 的简写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 bbband ccc):

例如，老提交了一个空白的错误（bbb），但你可以专注于新的错误只（在年底still bbb和ccc）：

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

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

---

---

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

在 Git 2.26（2020 年第一季度）中，diff-*管道子命令系列现在关注diff.wsErrorHighlight配置，这在之前被忽略了；这允许“ git add -p”也向最终用户显示空白问题。

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

请参阅Jeff King ( )提交的 da80635(2020 年 1 月 31 日)。^{（由Junio C Hamano合并-- --在df04a31 提交中，2020 年 2 月 14 日）}peff
gitster

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 diffitself.
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-highlightto 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.

diff: 将 diff.wsErrorHighlight 移动到“基本”配置

^{签字人：Jeff King}

我们将 diff.wsErrorHighlight 解析git_diff_ui_config()为 ，这意味着它对管道命令不起作用，仅对像git diff它一样的瓷器生效。
这有点烦人，因为它意味着像 那样的脚本add--interactive会产生用户可见的颜色差异，不尊重选项。

我们可以教该脚本解析配置并将其传递--ws-error-highlight给 diff 管道。但是有一个更简单的解决方案。

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

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

回答by Vebz

The whitespace error with visual images is shown here.

此处显示了视觉图像的空白错误。

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

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

回答by Marian

Because line begining with TABistead of SPACE. Go on patch file and replace TABwith SPACE. E.g. on vim on line + from patch file type x to remove space and not remove sign + and insert space (CTRL) on eqiv to original size.

因为以TABi 开头的行而不是SPACE. 继续补丁文件并替换TAB为SPACE. 例如，在 vim 上从补丁文件类型 x 删除空格而不是删除符号 + 并在 eqiv 上插入空格（CTRL）到原始大小。