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.这是什么意思？

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

正如您从man patch的描述中看到的那样，使用-U5版本创建的补丁在这种情况下需要更长时间才能应用，或者更糟糕的是，如果patch使用的模糊值1}}不够大，应用补丁会失败。

Answer 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的情况下，修补程序不干净，修补可能会失败或被模糊接受。

结论

首先考虑极端情况。如果你的上下文为零，那么修补错误或将数据应用于错误的行是非常东方的。如果你有无限的上下文，那么每个补丁基本上都会成为文件的完整替代品，因此很难对补丁进行重新排序。

所以很容易理解，太低和太高的背景都很糟糕。因此，显然应该在更好地匹配和发现个别变化之间进行权衡。

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

增加统一差异上下文行的数量是否有任何缺点？

2 个答案:

结论