在 Git 中浏览孤立提交

Browse orphaned commits in Git

提问by Ben Hymers

My git repository has somehow gone wonky - I loaded up msysgit this morning and instead of the branch name being shown after the current directory, it says "((ref: re...))", 'git status' reports everything as a new file, 'git log' and 'git reflog' tell me "fatal: bad default revision 'HEAD'", and so on.

我的 git 存储库不知何故变得不稳定 - 我今天早上加载了 msysgit，而不是在当前目录之后显示分支名称，而是显示“((ref: re...))”，'git status' 将所有内容报告为新文件，'git log' 和 'git reflog' 告诉我“致命：错误的默认修订版 'HEAD'”，等等。

Doing 'git reflog --all' or 'gitk --all' shows me the rest of the repository is intact, but it looks like the branch I was working on has just disappeared, which explains why HEAD doesn't seem to exist/point to anything.

执行 'git reflog --all' 或 'gitk --all' 向我显示存储库的其余部分完好无损，但看起来我正在处理的分支刚刚消失，这解释了为什么 HEAD 似乎不存在/指向任何东西。

I know git keeps hold of all sorts of globs of information, and I'm assuming my commits have just been orphaned somehow, so is there some command that will show me those commits so I can reset HEAD to them?

我知道 git 保存着各种各样的信息，我假设我的提交以某种方式被孤立了，那么是否有一些命令可以显示这些提交，以便我可以将 HEAD 重置为它们？

EDIT: Oh dear. I discovered 'git fsck', and 'git fsck --full' reports "fatal: object 03ca4... is corrupted". What the devil can I do about that?

编辑：哦，亲爱的。我发现了 'git fsck'，并且 'git fsck --full' 报告“致命：对象 03ca4... 已损坏”。我该怎么办？

EDIT: Oh dear oh dear. I checked out another branch, then tried to re-create the original branch with the same name using 'git checkout -b lostbranchname', and git says "error: unable to resolve reference refs/heads/lostbranchname: No error, fatal: Failed to lock ref for update: No error". 'No error' must be a particularly nasty error. So it looks like it's still hanging around, but unable to be used and unable to be killed.

编辑：哦，亲爱的哦，亲爱的。我检查了另一个分支，然后尝试使用 'git checkout -b lostbranchname' 重新创建具有相同名称的原始分支，并且 git 说“错误：无法解析引用 refs/heads/lostbranchname：没有错误，致命：失败锁定参考以进行更新：没有错误”。“没有错误”一定是一个特别讨厌的错误。所以看起来它仍然在徘徊，但无法使用也无法杀死。

EDIT: Super duper oh dear. I've done a bunch of unpacking and repacking and replacing of things as suggested here: How to recover Git objects damaged by hard disk failure?, but now I'm getting another hash reported as corrupt, for something as innocuous as 'git status'. I think the entire thing is hosed. Git's lovely and all, but I shouldn't have to deal with this kind of thing.

编辑：超级骗子哦，亲爱的。我已经按照此处的建议进行了大量的拆包、重新打包和替换：如何恢复因硬盘故障而损坏的 Git 对象？，但现在我收到另一个散列报告为已损坏，对于像“git status”这样无害的东西。我认为整个事情都被灌输了。Git 很可爱，但我不应该处理这种事情。

回答by Ben Hymers

Rather than leave this open I think I'll give an answer to my own question. Using git reflog --allis a good way to browse orphaned commits - and using the SHA1 hashes from that you can reconstruct history.

与其让这个开放，我想我会回答我自己的问题。使用git reflog --all是浏览孤立提交的好方法 - 使用 SHA1 哈希值可以重建历史记录。

In my case though, the repository was corrupted so this didn't help; git fsckcan help you find and sometimes fix errors in the repository itself.

不过，就我而言，存储库已损坏，因此这没有帮助；git fsck可以帮助您查找并有时修复存储库本身中的错误。

回答by VonC

With git 2.9.x/2.10 (Q3 2016), you won't have to use git reflog --allanymore, git reflogwill be enough.

使用 git 2.9.x/2.10（2016 年第 3 季度），您不必再使用git reflog --all，git reflog就足够了。

See commit 71abeb7(03 Jun 2016) by SZEDER Gábor (szeder).
^{(Merged by Junio C Hamano -- gitster--in commit 7949837, 06 Jul 2016)}

参见SZEDER Gábor ( ) 的commit 71abeb7(03 Jun 2016 )。^{（由Junio C Hamano合并-- --在commit 7949837，2016 年 7 月 6 日）}szeder
gitster

reflog: continue walking the reflogpast root commits

If a repository contains more than one root commit, then its HEAD reflog may contain multiple "creation events", i.e. entries whose "from" value is the null sha1.
Listing such a reflog currently stops prematurely at the first such entry, even when the reflog still contains older entries.
This can scare users into thinking that their reflog got truncated after 'git checkout --orphan'.

Continue walking the reflog past such creation events based on the preceeding reflog entry's "new" value.

reflog: 继续遍历reflog过去的根提交

如果存储库包含多个根提交，则其 HEAD 引用日志可能包含多个“创建事件”，即“from”值为空 sha1 的条目。
列出这样的 reflog 当前在第一个这样的条目处过早停止，即使 reflog 仍然包含较旧的条目。
这可能会吓到用户认为他们的 reflog 在 ' git checkout --orphan'之后被截断了。

根据前面的引用日志条目的“新”值，继续遍历引用日志经过此类创建事件。

回答by Jamey Hicks

One good feature of git is that it detects corruption. However, it does not include error correction to protect from corruption.

git 的一个优点是它可以检测损坏。但是，它不包括错误纠正以防止损坏。

I hope that you have pushed the contents of this repository to another machine or that you have backups to recover the corrupted parts.

我希望您已将此存储库的内容推送到另一台机器，或者您有备份来恢复损坏的部分。

I do not have any experience with git on windows but have never seen this sort of behavior with git on Linux or OS X.

我对 Windows 上的 git 没有任何经验，但从未见过在 Linux 或 OS X 上使用 git 的这种行为。