为什么 `git stash -p` 有时会失败？

Question

我♥git stash -p。但有时，在一次令人满意的 y、n 和 s 会话之后，我会明白：

Saved working directory and index state WIP on foo: 9794c1a lorum ipsum
error: patch failed: spec/models/thing_spec.rb:65
error: spec/models/thing_spec.rb: patch does not apply
Cannot remove worktree changes

为什么？

Answer 1

每当我尝试将一个大块拆分为距离太近的较小块（更改之间的行数少于 3 行）时，这种情况就会发生在我身上。简而言之，该补丁中的上下文行与您的本地更改发生冲突。下面有更完整的解释。

---

假设我有一个包含这些未提交更改的 git 存储库：

--- a/pangram
+++ b/pangram
@@ -1,8 +1,8 @@
 The
-quick
+relatively quick
 brown
 fox
-jumps
+walks
 over
 the
 lazy

如果我存储第一个更改，我会得到：

--- a/pangram
+++ b/pangram
@@ -1,5 +1,5 @@
 The
-quick
+relatively quick
 brown
 fox
 jumps

git stash 命令实际上确实成功保存了补丁（检查 git stash list ） >)，但随后 git 反向使用该补丁来删除我的工作目录中隐藏的更改。大块头之后的上下文有“跳跃”，这与仍在我的工作目录中的“行走”不匹配。因此 git 会放弃

error: patch failed: pangram:1
error: pangram: patch does not apply
Cannot remove worktree changes

并将所有更改保留在我的工作目录中，并且存储变得几乎毫无价值。

---

我认为这是 git 块分割支持中的一个错误。如果它知道它把更改分割得太近，它可能会从补丁中删除几行上下文，或者吉米补丁以获得修改后的上下文行而不是原始的上下文行。或者，如果官方不支持如此接近的分裂帅哥，那么它实际上应该拒绝如此接近的分裂帅哥。

Answer 2

git stash -p 使用 Git 2.17（2018 年第 2 季度）应该会减少失败。
在此之前，“git add -p”（与 git stash 共享逻辑）在将结果传递给底层“git apply”之前一直懒于合并分割补丁。 ”，导致极端情况错误；在大块选择之后准备要应用的补丁的逻辑已经收紧。

请参阅 提交 3a8522f、提交 b3e0fcf, 提交 2b8ea7f（2018 年 3 月 5 日），提交 fecc6f3，提交 23fea4c，提交 902f414（2018 年 3 月 1 日），以及提交 11489a6， 提交 e4d671c，提交 492e60c（2018 年 2 月 19 日），作者：Phillip Wood (菲利普伍德）。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 436d18f，2018 年 3 月 14 日）}

add -p：跳过一个块时调整后续块的偏移量

（添加，但同样可以应用于存储）

自从提交8cbd431（“git-add--interactive：替换大块
使用 apply --recount 重新计数”，2008-7-2，Git v1.6.0-rc0）如果跳过了一个块，那么我们依靠上下文行来应用右侧的后续块
地点。

虽然这在大多数情况下都有效，但帅哥们还是有可能
最终被应用在错误的地方。

要解决此问题，请调整偏移量
的后续帅哥来纠正数量的任何变化
由于跳过的块而导致的插入或删除。偏移量的变化
由于编辑过的大块有大量的插入或删除
此处忽略更改，它将在下一次提交中修复。

您可以在此处查看一些测试。

---

Git 2.19 改进了 git add -p：当用户在“git add -p”中编辑补丁并且用户的编辑器设置为不加区别地去除尾随空格时，会出现一个空行补丁中未更改的内容将变得完全空（而不是带有唯一 SP 的行）。
Git 2.17 时间范围中引入的代码无法解析这样的补丁，但现在它学会了注意到这种情况并应对它。

请参阅 提交 f4d35a6（2018 年 6 月 11 日），作者：菲利普·伍德 (phillipwood)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 5eb8da8，2018 年 6 月 28 日）}

add -p：修复编辑补丁中空上下文行的计数

recount_edited_hunk() 在 commit 2b8ea7f 中引入 ("添加-p：
计算已编辑补丁的偏移量增量”，2018-03-05，Git v2.17.0）要求所有上下文行以空格开头，空行不计算在内。
这是为了避免用户在编辑补丁时在末尾引入空行时出现任何重新计数问题。

然而，这引入了“git add -p”的回归，因为编辑器在编辑补丁时似乎通常会从空上下文行中删除尾随空格，从而引入应该被删除的空行。
已计算。
'git apply' 知道如何处理此类空行，并且 POSIX 规定空上下文行上是否有空格是实现定义的（请参阅 diff 命令）。

通过计算仅包含换行符的行来修复回归
以及以空格开头的行作为上下文行并添加测试
以防止未来的回归。

---

Git 2.23（2019 年第 3 季度）改进了“git checkout -p”使用的 git add -p，它需要选择性地反向应用补丁：效果不佳前。

请参阅 提交 2bd69b9（2019 年 6 月 12 日），作者：菲利普·伍德 (phillipwood)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 1b074e1，2019 年 7 月 9 日）}

add -p：使用病态上下文修复checkout -p

提交fecc6f3 ("add -p: 调整后续块的偏移量，当一个块
已跳过”，2018-03-01，Git v2.17.0-rc0）修复了当跳过前一个块时在正确位置添加块。

但是它没有解决反向应用的补丁。

在这种情况下，我们需要调整前图像偏移，以便在应用反转补丁时正确调整后图像偏移。
当补丁被反转时，我们减去而不是添加增量（考虑它的最简单方法是考虑跳过一大块删除 - 在这种情况下我们想要减少偏移量，所以我们需要减去）。

---

在 Git 2.25（2020 年第一季度）中，将“git-add--interactive”Perl 脚本移至 C 的工作仍在继续。

因此，重新实施了上述修复。

请参阅 提交 2e40831、提交 54d9d9b, 提交 ade246e、提交 d6cf873、提交 9254bdf, 提交 b38dd9e，提交 11f2c0d, 提交 510aeca，提交 0ecd9d2，提交 5906d5d，提交 47dc4fd，提交 80399ae，提交7584dd3，提交 25ea47a，提交 e3bd11b, 提交 1942ee4、提交 f6aa7ec（2019 年 12 月 13 日） ）作者：Johannes Schindelin (dscho)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 45b96a6，2019 年 12 月 25 日）}

内置add -p：调整块根据需要标头

^{签字人：Johannes Schindelin}

当跳过添加的行数与删除的行数不同的块时，我们需要调整非跳过块的后续块标头：在病态情况下，上下文不足以准确确定应应用补丁的位置.

此问题已在 23fea4c240 ("t3701 ：add 病理上下文行测试失败”，2018-03-01，Git v2.17.0-rc0 -- 合并 ) 并在 rel="noreferrer"> 中的 Perl 版本中修复fecc6f3a68< /a> ("add -p: 当跳过一个块时调整后续块的偏移量", 2018-03-01, Git v2.17.0-rc0 -- 合并)。

这个补丁在 git add -p 的 C 版本中修复了这个问题。

与 Perl 版本相比，我们尝试保持 hunk 标头上的额外文本（通常包含在 hunk 中更改代码的函数的签名）完好无损。

注意：虽然 C 版本现阶段不支持暂存模式更改，但我们已经为此做好准备，如果旧的和新的偏移量均为 0，则只需跳过 hunk 标头（这对于常规 hunk 不会发生，我们将使用这表明我们正在寻找一个特殊的帅哥）。

同样，我们已经通过优雅地处理块标题中缺少额外文本来准备块分割：只有第一个分割块才会有该文本，其他的不会（由空的额外文本开始/结束范围表示） 。在此阶段准备块分割可以避免稍后整个块标题打印块的缩进更改，并且几乎与不进行该处理一样容易检查。

---

在 Git 2.27（2020 年第 2 季度）之前，允许用户拆分补丁块，而“git stash -p”效果不佳；添加了创可贴以使其（部分）发挥更好的作用。

请参阅 提交 7723436、提交 121c0d4（2020 年 4 月 8 日），作者：Johannes Schindelin (dscho)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 e81ecff，2020 年 4 月 28 日）}

stash -p：（部分）修复错误关于分裂帅哥

^{签字人：Johannes Schindelin}

当尝试通过分割一个大块然后仅部分接受分割的片段来存储部分工作树更改时，用户会遇到一个相当神秘的错误：

错误：补丁失败：<文件>：<行>
错误：测试：补丁不适用
无法删除工作树更改

并且该命令将无法存储工作树更改的所需部分（即使 stash 引用实际上已正确更新）。

我们甚至有一个测试用例来证明这种失败，并且已经运行了四年。

解释：当分割一个块时，更改的行不再被超过 3 行分隔（这是 Git 的 diff 默认使用的上下文行数），而是少于 3 行。

因此，当仅暂存部分 diff 块时，我们想要反向应用到工作树的结果 diff 将包含要删除的由三个上下文行包围的更改，但由于 diff 是相对于 HEAD 的，而不是与工作树相比，这些上下文行将不匹配。

示例时间。假设文件 README 包含以下行：

<前><代码>我们
这
人们

并且工作树添加了一些行，以便它包含这些行：

<前><代码>我们
是
这
种类
人们

并且用户尝试存储包含“are”的行，然后该命令将在内部将此行暂存在临时索引文件中，并尝试恢复 HEAD 和该索引文件之间的差异。
git stash 尝试恢复的 diff 块看起来有点像这样：

<前><代码>@@ -1776,3 +1776,4
我们
+是
这
人们

现在很明显，尾随上下文行与用户不想隐藏的原始差异块的部分重叠。

请记住，差异中的上下文行的主要目的是当差异不精确应用时查找确切位置（但是当要修补的文件中的确切行号与差异中指示的行号不同时） ，我们通过减少上下文行的数量来解决这个问题：差异刚刚生成。

注意：这不是问题的完整修复。
正如 t3701 的“add -p 适用于病态上下文行”测试用例所示，diff 格式存在歧义。当然，在实践中很少会遇到这样的重复行。

这种情况的完整解决方案是替换从存储中生成差异，然后通过模拟 git revert 反向应用它的方法（即进行 3 路合并）。但是，在 git stash -p 中，它不会应用于 HEAD 而是应用于工作树，这使得只要我们还维护脚本版本，实现起来就很困难add -i。

---

Git 2.29（2020 年第 4 季度）为 git add -p（由 stash -p 使用）带来了泄漏修复，

请参阅 提交 324efcf（2020 年 9 月 7 日），作者：Phillip Wood (<代码>菲利普伍德）。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 3ad8d3e，2020 年 9 月 18 日）}

添加-p：修复内存泄漏

^{签字人：Phillip Wood
确认人：约翰内斯·辛德林}

asan 报告 C 版本的 add -p 没有释放它分配的所有内存。

通过引入一个函数来清除 struct add_p_state`` 并使用它而不是释放单个成员来修复此问题。

Answer 3

在 git stash -p 以同样的方式失败后，我很幸运地使用了这个解决方法（git 2.0.2）：

• git add -p，拆分完全相同的内容帅哥，但答案相反（“y”到add“保留”更改，“n”到stash保留更改。）
• git stash -k保留索引并存储其他所有内容
• git重置以继续处理我的文件

我不确定为什么git add -p没有以与git add -p相同的方式失败code>git stash -p 做到了。我想是因为添加与索引一起工作而不是创建补丁文件？

Answer 4

不幸的是，即使在 Git 2.17 中，目前接受的答案仍然可能失败。

如果像我一样，您花费了大量精力来构建完美的存储，并且不想放弃这些努力，那么仍然可以通过以下方式大部分获得您想要的东西：

git stash show -p | patch -p1 -R

这会失败并被拒绝，但很有可能大多数帅哥都会正确应用，并且至少可以节省您再次检查所有文件的时间。