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

本文介绍了为什么`git stash -p`有时会失败？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 29岁程序员，3月因学历无情被辞！ 我♥ git stash -p 。但有时，在满足 y ， n 和 s ，我得到这个： pre $ 保存的工作目录和索引状态foo上的WIP：9794c1a lorum ipsum 错误：修补程序失败：spec / models / thing_spec.rb：65 错误：spec / models / thing_spec.rb：修补程序不适用无法删除工作树更改 p> 为什么？解决方案 git stash -p 在使用Git 2.17（Q2 2018）时应该会少一些。 在此之前， git add -p （它与 git stash 共享逻辑）在将结果传递给底层的 git apply ，导致个案错误;准备在大块选择后应用的补丁的逻辑已被收紧。 请参阅 commit 3a8522f ， commit b3e0fcf ，提交2b8ea7f （2018年3月5日）， commit fecc6f3 ， commit 23fea4c ， commit 902f414 （201年3月1日） ）和 commit 11489a6 ， commit e4d671c ， commit 492e60c （2018年2月19日） Phillip Wood（ phillipwood ）。 add -p ：调整后面的hunk的偏移量当一个被跳过时 （添加，但是可以应用于存储） 由于 commit 8cbd431 （ git-add - interactive ：replace hunk 使用apply --recount进行重新计算，2008-7-2，Git v1.6.0-rc0）如果跳过了一个块，那么我们依赖上下文行将后续块应用到正确的位置。 尽管这在大多数情况下都有效，但是可能最糟糕的情况是最终被应用在错误的地方。 为了解决这个问题，我们调整后续hunk的偏移量，以校正由于跳过的hunk而引起的插入或删除次数的任何变化。 由于编辑的插入或删除数量发生了变化而发生的更改在此处将被忽略，它将在下一次提交中修复。 您可以在这里看到一些测试。 I ♥ git stash -p. But sometimes, after a satisfying session of y, n, and s, I get this:Saved working directory and index state WIP on foo: 9794c1a lorum ipsumerror: patch failed: spec/models/thing_spec.rb:65error: spec/models/thing_spec.rb: patch does not applyCannot remove worktree changesWhy? 解决方案 git stash -p should fail less with Git 2.17 (Q2 2018).Before that, "git add -p" (which shares logic with git stash) has been lazy in coalescing split patches before passing the result to underlying "git apply", leading to corner case bugs; the logic to prepare the patch to be applied after hunk selections has been tightened.See commit 3a8522f, commit b3e0fcf, commit 2b8ea7f (05 Mar 2018), commit fecc6f3, commit 23fea4c, commit 902f414 (01 Mar 2018), and commit 11489a6, commit e4d671c, commit 492e60c (19 Feb 2018) by Phillip Wood (phillipwood). add -p: adjust offsets of subsequent hunks when one is skipped(add, but again, can be applied to stash) Since commit 8cbd431 ("git-add--interactive: replace hunk recounting with apply --recount", 2008-7-2, Git v1.6.0-rc0) if a hunk is skipped then we rely on the context lines to apply subsequent hunks in the right place. While this works most of the time it is possible for hunks to end up being applied in the wrong place. To fix this adjust the offset of subsequent hunks to correct for any change in the number of insertions or deletions due to the skipped hunk. The change in offset due to edited hunks that have the number of insertions or deletions changed is ignored here, it will be fixed in the next commit.You can see some tests here. 这篇关于为什么`git stash -p`有时会失败？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！