Question

我最近在SO上发现了answer。它提供了有关如何撤消已应用存储所做更改但仍保留对文件的其他更改的方法。我试过通过提供的脚本作为示例，但我的补丁失败了：

Checking patch messages... 
error: while searching for: 
Hello, world 
Hello again 

error: patch failed: messages:1

我注意到答案是2009年，这种方法今天有效吗？我也很好奇的是，当git应用补丁时，AFAIK会在更改之前和之后搜索上下文行，但在问题的示例中，更改后的上下文不匹配，如何＆＃39 ;然后是一个应该应用的补丁？

Answer 1

存储只是一个提交，因此可以恢复。

我们假设你做了

list_length/1

以后

git stash

将恢复工作目录中的更改。现在你继续工作，你修改其他文件。最后，您将所有更改作为新提交提交。

现在，如果您只想恢复来自存储的更改，那么如果您知道存储的提交ID，则可以执行此操作。由于你做了一个stash pop它已经消失了，git不会创建一个reflog条目。

但你可以恢复它搜索悬空提交。 E.g。

git stash pop

但如果你使用gitk

会更容易

git fsck --no-reflog | awk '/dangling commit/ {print $3}'

查找合并提交。 Git将存储存储为合并提交，因为它将实际暂存的更改保存在名为gitk --all $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' )的提交中，并且实际工作目录会随着阶段更改的合并提交和存储所依赖的HEAD而更改。

在git中，存储提交看起来像这样：

index on trunk: ...

如果你找到了藏匿提交，你可以使用它的id恢复它。根据上面的例子，你会做一个

  HEAD
    |
    V
A---B---D <-- stash commit
     \ /
      C <-- staged changes commit

反向修补隐藏的更改保留新的更改 - 为什么反向修补失败

1 个答案: