应用补丁时，“一行代码增加了空格错误”是什么意思？

Question

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

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

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

这个警告信息是什么意思，我需要关心它吗？

- Yarin

---

相关问题 ("为什么？"): https://dev59.com/XHI-5IYBdhLWcg3w-9wK - Mechanical snail

Answer 1

你不需要关心。

这个警告实施了文本文件中空格的规范性，这是许多程序员倾向于关心的事情。正如手册所解释的：

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

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

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

- user4815162342

---

使用 git show 命令查看提交记录，如果你的 git 支持颜色，你会看到有问题的空格以愤怒的红色显示。此外，git show --word-diff 命令不仅会显示行的变化，还会显示行中间的插入内容，这将显示补丁是否真的只在中间添加了一个单词，或者它是否还添加了尾随空格。 - user4815162342

你并不需要关心，但你应该关注。尾随空格应该被清除。 - funroll

除非 OP 添加新的尾随空格，否则只修改已存在的内容。 - user4815162342

我曾在类似情况中看到过这种问题的出现，当行末使用的是Windows格式(CRLF)而不是Unix格式时。 - Ezequiel Muns

好的，那如果你确实关心呢？你如何找到错误？ - Edward Falk

Answer 2

当你想区分“旧”的空格错误（可能出于遗留原因而保留）和“新”的空格错误（你想避免的情况）时，你可以合法地关心一个案例。

为此，Git 2.5+（2015年第二季度）将提供更具体的选项来检测空格。

查看由Junio C Hamano (gitster)于[2015年5月26日]提交的commits 0e383e1, 0ad782f和d55ef3e。
^{（由Junio在[2015年6月11日]合并，提交709cd91）}

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年第一季度），差异diff-*子命令的plumbing家族现在会注意diff.wsErrorHighlight配置了，而这之前被忽略；这使得“git add -p”也可以向最终用户显示空格问题。

请参见提交da80635（2020年1月31日）由Jeff King（peff）撰写。
^{（由Junio C Hamano -- gitster --于提交df04a31中合并，2020年2月14日）}

diff: 将 diff.wsErrorHighlight 移动到“basic”配置中

^{签名：Jeff King}

我们在 git_diff_ui_config() 中解析 diff.wsErrorHighlight，这意味着它不会对管道命令产生影响，只会影响像 git diff 这样的工具。
这有点烦人，因为这意味着像 add--interactive 这样的脚本，生成带颜色的用户可见差异时，无法遵循该选项。

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

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

因此，我们只需将其移动到“basic”配置中，即可解决 add--interactive 和其他处于同样困境的脚本问题，而极低风险伤害任何管道用户。

- VonC

Answer 3

这里显示了与可视图像相关的空格错误。

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

- Vebz

Answer 4

对我来说它有效：

git config apply.whitespace fix

在每次提交之前使用：

git add -up .

- Tomasz

Answer 5

因为行首使用了TAB而不是SPACE。请打开补丁文件并将TAB替换为SPACE。例如，在vim中，对于来自补丁文件的第+行，键入x以删除空格而不删除符号+，然后插入空格（CTRL）以保持原始大小。

- Marian

---

你真的认为git会抱怨Linus风格的制表符缩进吗？如果有的话，唯一合法的制表符使用就是在行的开头。 - user2394284