4

我在损坏的存储库中丢失了提交对象，但仍有一些文件和树对象：

$ git fsck                                                
Checking object directories: 100% (256/256), done.
dangling blob 031be26142ed97da216fb7d79d16a0b0efdf0d71
dangling blob 4b2be7dfef082c2e247be52e6d78600af7b6dd40
dangling tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
dangling blob ccbb1056cb4e744f9a4b44a439fa036f6a3d7cbe
dangling blob 10bfbc3c1fa10e08cd6a783565f00e7324f61fe5
dangling blob 9b529957be714fef304c4e8161fe6cd138510e98
dangling blob dd5b54882d0b74db99c8a7fbba703d528dc559b9

有没有办法检查那个树对象？

我想可能有一种方法可以使用虚拟提交字符串重建提交对象并检查它。

git cat-file -p tree-sha1
4

3 回答 3

6

If you git checkout 4b825dc642cb6eb9a060e54bf8d69288fbee4904 . (the dot for a path name is important, otherwise git will interpret it as a branch switch operation and refuse) it will update all of the files in both the working directory and the index to match the state of 4b825d... (that is, git diff will show nothing, git diff --staged will show a lot of changes, and git status will show a lot of M). You can inspect the state of the files that way.

If you have a guess at a relevant parent commit, you can

git checkout -b recover relevant_parent
git checkout 4b825dc642cb6eb9a060e54bf8d69288fbee4904 .
git commit -m "Recovered this thing that git fsck told me about"

to give it a commit and a branch to address it by.

于 2013-07-11T21:24:39.403 回答
4

如果这种情况经常发生，或者如果您需要在其他提交中来回切换，您可以创建一个指向该树的新提交对象，然后为方便起见创建一个指向它的新分支：

git commit-tree <<treeid>>
<<type a commit message>>
^D
<<this will produce a hash for the new commit object>>
git branch newbranch <<newcommithash>>

然后，您应该能够git checkout newbranch在需要时...

于 2013-07-11T23:13:41.833 回答
3

尝试

git read-tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904

或者更干净一些

git read-tree --prefix=rescue --index-output=/tmp/rescue.index b825dc642cb6eb9a060e54bf8d69288fbee4904

将其放入子文件夹（救援）。

请务必检查树所指的内容，它可能不是存储库根路径：

于 2013-07-11T21:20:51.887 回答