git - 增加统一差异上下文行的数量有什么缺点吗？

Question

默认情况下，diff -u使用git diff上下文行生成统一差异。除了 diff 文件本身的大小之外，增加上下文行数有什么缺点吗？我认为它可能会在要修补的文件自补丁制作以来已被修改的情况下有所帮助。具体来说，如果您增加上下文行的数量，是否存在patch会失败的情况，如果您没有这样做，则不会出现这种情况？

Answer 1

是的。考虑以下情况：

有一个文件f1：

a
b
c
d
e
f
g

您修改该f行，并获得

--- f1  2013-04-15 13:23:57.524966109 +0200
+++ f2  2013-04-15 13:25:17.832965720 +0200
@@ -5,3 +5,3 @@
 e
-f
+f2
 g

或者

--- f1  2013-04-15 13:23:57.524966109 +0200
+++ f2  2013-04-15 13:25:17.832965720 +0200
@@ -1,7 +1,7 @@
 a
 b
 c
 d
 e
-f
+f2
 g

取决于您是否使用-U1或-U5选项diff。现在假设其他人编辑了文件的上半部分，如下所示：

a
b1
c
d
e
f
g

这是两个patch命令的输出：

$ patch f3 < u1.patch 
patching file f3
$ patch f3 < u5.patch 
patching file f3
Hunk #1 succeeded at 1 with fuzz 2.

该补丁在两种情况下都成功应用，但是，在第二次运行中，我们不得不使用模糊值 2。这是什么意思？

第一个补丁查找上下文的所有行都匹配的位置。如果没有找到这样的地方，并且它是上下文差异，并且最大模糊因子设置为 1 或更大，则忽略上下文的第一行和最后一行进行另一次扫描。如果失败，并且最大模糊因子设置为 2 或更大，则忽略上下文的前两行和最后两行，并进行另一次扫描。

从 的描述中可以看出，在这种情况下，man patch使用该版本创建的补丁-U5将需要更长的时间才能应用，甚至更糟糕的是，如果使用的 fuzz 值patch不够大，应用补丁将失败。

Answer 2

上下文的大小对补丁有两个主要影响：

1. 上下文越大，您就越确定在正确的上下文中应用补丁。
2. 上下文越大，可以将更多的变化归为一组。

考虑以下示例（故意拼写错误）：

original file:                     Changed file:

This is                            This is
some tex.                          some text.
You are on                         You are on
stackoverflo.com                   stackoverflo.com
Completely unrelated               Completely unrelated
tet here.                          text here.
Goodbye.                           Goodbye.

其中 1 行的上下文大小，你会得到一个有两个大块的补丁：

@@ -1,2 +1,3 @@
 This is
-some tex.
+some text.
 You are on
@@ -4,3 +5,3 @@
 Completely unrelated
-tet here.
+text here.
 Goodbye.

并且上下文大小为 3 行，您将获得一个包含一个大块的补丁：

@@ -1,6 +1,7 @@
 This is
-some tex.
+some text.
 You are on
 stackoverflo.com
 Completely unrelated
-tet here.
+text here.
 Goodbye.

现在想象第二个修复：

Changed file:                      Further changed file:

This is                            This is
some text.                         some text.
You are on                         You are on
stackoverflo.com                   stackoverflow.com
Completely unrelated               Completely unrelated
text here.                         text here.
Goodbye.                           Goodbye.

这里的补丁是：

@@ -3,3 +3,3 @@
 You are on
-stackoverflo.com
+stackoverflow.com
 Completely unrelated

现在，假设您颠倒了修补的顺序。因此，您首先应用第二个补丁（修复flow地址），然后应用第一个补丁（使用-U 1或-U 3）。

• -U 1在补丁的情况下应用干净。
• 在补丁不干净的情况下，-U 3补丁可能会失败或被模糊接受。

结论

首先考虑极端情况。如果您的上下文为零，那么将补丁弄错或将大块应用于错误的行是非常东方的。如果你有无限的上下文，那么每个补丁基本上都会成为文件的完整替换，从而很难重新排序补丁。

所以很容易理解，太低和太高的上下文都是不好的。因此，显然应该在更好的匹配和发现个体变化之间进行权衡。

不幸的是，没有最佳的行数，可以说默认上下文大小是开发人员集体接受的公平权衡。如果它有助于你的事业，你可以增加它，但要小心它的影响。