git fsck 结合 --lost-found 和 --unreachable

我发现了很多有趣的帖子git fsck，所以我想对它们进行一些实验。首先我在这个问题之前阅读的资料来源：

• 如何通过关键字在 GIT 存储库中找到无法访问的提交哈希？ https://stackoverflow.com/questions/31388918/how-can-i-find-an-unreachable-commit-hash-in-a-git-repository-by-keywords

• git fsck： --dangling 与 --unreachable 与 --lost-found 有什么不同？ https://stackoverflow.com/questions/36621730/git-fsck-how-dangling-vs-unreachable-vs-lost-found-differ

• 获取所有 git 提交的列表，包括“丢失”的提交 https://stackoverflow.com/questions/4786972/get-a-list-of-all-git-commits-including-the-lost-ones

我从这个仓库开始：

* 9c7d1ea (HEAD -> test) f
* cd28884 e
| * 7b7bac0 (master) d
| * cab074f c
|/  
* d35af2c b
| * f907f39 r # unreferenced commit
|/
* 81d6675 a

Where r是从一个独立的HEAD from a。 然后我想重新建立基础master on test，但我有一些未分阶段的更改，所以我这样做了：

git rebase --autostash test

获取（我没有显示r但它仍然存在）：

* caee68c (HEAD -> master) d
* 2e1cb7d c
* 9c7d1ea (test) f
* cd28884 e
* d35af2c b
* 81d6675 a

接下来我运行：

$ git fsck
#...
dangling commit 6387b70fe14f1ecb90e650faba5270128694613d # stash
#...

$ git fsck --unreachable
#...
unreachable commit 6387b70fe14f1ecb90e650faba5270128694613d # stash
unreachable commit d8bb677ce0f6602f4ccad46123ee50f2bf6b5819 # stash index
#...

$ git fsck --lost-found
#...
dangling commit 6387b70fe14f1ecb90e650faba5270128694613d # stash
dangling commit f907f39d41763accf6d64f4c736642c0120d5ae2 # r
#...

第一个问题

为什么只有--lost-found版本返回r犯罪？为什么不是c and d之前rebase显示在无法访问的范围内？我以为我理解了阅读链接问题的区别，但我显然错过了一些东西。我仍然有完整的引用日志，但我想你不需要它，因为所有提交（除了那些与stash) 被引用。

我知道我应该创建另一篇文章，但第二个问题部分相关。出于好奇我尝试了一下：

$ git fsck --lost-found --unreachable
#...
unreachable commit 6387b70fe14f1ecb90e650faba5270128694613d # stash
unreachable commit d8bb677ce0f6602f4ccad46123ee50f2bf6b5819 # stash index
unreachable commit f907f39d41763accf6d64f4c736642c0120d5ae2 # r
unreachable commit 7b7bac0608936a0bcc29267f68091de3466de1cf # c before rebase
unreachable commit cab074f2c9d63919c3fa59a2dd63ec874b0f0891 # d before rebase
#...

第二个问题

结合这两个选项，我得到了所有无法访问的提交（而不仅仅是--lost-found and --unreachable），这是非常出乎意料的。为什么它会这样？

其中一些确实令人费解，并且似乎没有正确记录，但快速浏览一下内置/fsck.c https://github.com/git/git/blob/225365fb5195e804274ab569ac3cc4919451dc7f/builtin/fsck.c#L767-L801表明使用--lost-found:

1. 打开--full;
2. 打开--no-reflogs.

Item 1 isn't particularly interesting since --full is now on by default anyway, but the documentation really should call out that --lost-found disables --no-full. Item 2 explains most of the rest; I have a guess at the last part [Edit: the rest].

请注意，当您运行时：

git checkout master && git rebase --autostash test

这使得 Git 运行起来git stash push，这创建了一个由两个新提交组成的新存储。然后 Git 像往常一样进行 rebase，复制了cab074f and 7b7bac0提交，在原始版本中可见git log --all --decorate --oneline --graph输出，到新的2e1cb7d and caee68c提交在第二个输出中可见。

为什么只有--lost-found版本返回r犯罪？为什么不是c and d在无法访问的变基之前显示？

大概该提交仍在HEAD重新记录。这使得它可以通过引用到达 - 但因为--lost-found暗示--no-reflogs，这次就变得无法访问了。原件也是如此c and d：可以通过多个引用日志条目访问它们HEAD的重新记录和master's.

结合这两个选项，我得到了所有无法访问的提交（而不仅仅是--lost-found and --unreachable），这是非常出乎意料的。为什么它会这样？

That's more puzzling. [Edit: solved; see below.] Let's run these in order of your git fsck commands:

• fsck 1 和 fsck 2：两者都发现自动存储提交。那是因为git stash push复制了原件refs/stash到存储重新日志，以便refs/stash可以指向自动存储w（工作树）提交。那么隐含的git stash apply && git stash drop (git stash pop）应用了藏匿物并将其丢弃，移动了stash@{1}条目返回到refs/stash并删除隐藏的引用日志。所以w来自自动存储的提交确实是“悬而未决”的。它不在refs/stash它甚至不在stash转发，因为git stash(ab) 使用此 reflog 作为“存储堆栈”。然而，它确实指出i从自动存储提交。

  然后，第一个 fsck 打印6387b70fe14f1ecb90e650faba5270128694613d并称其为“悬空”。这就是w被删除的提交。第二fsck, with --unreachable, adds d8bb677ce0f6602f4ccad46123ee50f2bf6b5819： 相应的i被删除的提交。

• fsck 3：r并且重新调整的提交在以下情况下仍然不可见git fsck --unreachable因为它们是从引用日志中引用的。但现在，随着--lost-found，fsck 不查看 reflog。我们应该期待看到自动存储w提交，将r提交和预变基d，都像悬空一样。 [Edit： 按照comment https://stackoverflow.com/questions/66401232/git-fsck-combining-lost-found-and-unreachable/66405506?noredirect=1#comment117400592_66405506，这是错误的：w链接回i and d，所以这将隐藏d.]

  We actually see the w and r commits but not the d commit. Why not? This is my guess but it's easy to test if you still have the setup around: when you use git rebase successfully, Git creates or updates the pseudo-ref named ORIG_HEAD to remember the hash ID of the tip commit before the rebase completes. Note that this same name is used to remember the previous value of a ref after a successful git reset that moves one, and after any other operation that might move a branch name some distance (fast-forward merge, for instance).

  It's pretty obvious that git fsck must consider all of the various *_HEAD pseudo-refs as starting points for reachability. This, too, is not documented (and it's not even completely clear it's intentional here—the ref code has been under some fairly heavy rework lately, to support alternative ref backends).

• fsck 4, just before your SECOND QUESTION section: either --unreachable turned off the pseudoref inclusion, or—I think this is more likely—you did something in between that touched ORIG_HEAD so that it no longer selected the original, pre-rebase d commit. [edit] Since --unreachable lists all unreachable commits, the fact that d is reachable indirectly from the autostash w commit is irrelevant, and we see everything.

如果您想报告 Git 文档错误，fsck 文档没有指出--lost-found暗示--no-reflogs，你应该这样做。