如何修复从树到树的 Git 错误断开链接？

Question

我的事务被中断，当我再次尝试时，我遇到了空或损坏的对象错误，在另一个问题之后我删除了所有空文件，当我运行时

git fsck --full

我收到了这个错误：

Checking object directories: 100% (256/256), done.
Checking objects: 100% (48774/48774), done.
error: d193ccbc48a30e8961e9a2515a708e228d5ea16d: invalid sha1 pointer in cache-tree
error: df084ac4214f1a981481b40080428950865a6b31: invalid sha1 pointer in cache-tree
broken link from    tree 4bf4869299b294be9dee4ecdcb45d2c204ce623b
          to    tree df084ac4214f1a981481b40080428950865a6b31
broken link from    tree 4bf4869299b294be9dee4ecdcb45d2c204ce623b
          to    tree d193ccbc48a30e8961e9a2515a708e228d5ea16d
missing tree df084ac4214f1a981481b40080428950865a6b31
missing blob a632281618ca6895282031732d28397c18038e35
missing tree d193ccbc48a30e8961e9a2515a708e228d5ea16d
missing blob 70aa143b05d1d7560e22f61fb737a1cab4ff74c6
missing blob c21c0545e08f5cac86ce4dde103708a1642f23fb
missing blob 9f341b8a9fcd26af3c44337ee121e2d6f6814088
missing blob 396aaf36f602018f88ce985df85e73a71dea6f14
missing blob 87b9d1933d37cc9eb7618c7984439e3c2e685a11

我该如何解决这个问题？

Git

Answer 1

使用 Git 2.10（2016 年第三季度），您可以了解更多关于这些断开链接的来源。

git fsck --name-objects

见commit 90cf590，commit 1cd772c，commit 7b35efd，commit 993a21b（2016 年 7 月 17 日）Johannes Schindelin (dscho)。
^{（由 Junio C Hamano -- gitster -- 合并到 commit 9db3979，2016 年 7 月 25 日）}

fsck: 可选地显示更多有用的信息以了解断开的链接

当报告提交/树/blob 之间的断开链接时，如果用户被告知对象应该如何被访问，有时会非常有帮助。

使用新的--name-objects 选项，git-fsck 将尝试做到这一点：
以显示对象可访问性的方式命名对象。

例如，当某些 reflog 损坏并且丢失了不应该存在的 blob 时，用户可能希望删除相应的 reflog 条目。
此选项可帮助他们找到该条目：git fsck --name-objects 现在将报告如下内容：

  broken link from    tree b5eb6ff...  (refs/stash@{<date>}~37:)
                to    blob ec5cf80...

如果这些损坏的链接不是来自本地存储，而是来自远程仓库，fetching those pack objects can then solve the situation。
另见“How to recover Git objects damaged by hard disk failure?”。

---

使用 Git 2.31（2021 年第一季度），修复“git fsck --name-objects”^(man)，显然没有被任何有足够动力报告损坏的人使用。

参见commit e89f893、commit 8c891ee（2021 年 2 月 10 日）Johannes Schindelin (dscho)。
^{（由 Junio C Hamano -- gitster -- 合并到 commit 9e634a9，2021 年 2 月 17 日）}

fsck --name-objects: 更小心解析世代数

^{签字人：约翰内斯·辛德林}

在7b35efd 中（fsck_walk()：可选地在旅途中命名对象，2016-07-17，Git v2.10.0-rc0 -- merge 列在batch #7 中）(fsck_walk()：可选地命名对象go, 2016-07-17)，fsck 机器学会了选择性地命名对象，以便更容易看到存储库的哪个部分处于不良状态，例如，当对象丢失时。

为了节省复杂性，该机器使用解析器来确定给定提交名称的父级名称：解析任何~<n> 后缀，父级名称由前缀和~<n+1> 组成。

然而，这个解析器有一个错误：如果它找到一个后缀<n> 不是 ~<n>，它会将空字符串误认为是前缀，<n> 是代号.
换句话说，它将生成一个~<bogus-number> 形式的名称。

让我们解决这个问题。

Answer 2

解决此“断开的链接”错误的方法是 the answer from sehe 在此处列出，以回答有关如何修复无法找到 错误的问题。

就像亚当说的，从另一个存储库/克隆中恢复对象。

1. 在“完整”的 Git 数据库上：

   git cat-file -p a47058d09b4ca436d65609758a9dba52235a75bd > tempfile
   

2. 在接收端：

   git hash-object -w tempfile
   

一个重要的补充是在第 1 步和第 2 步之间，直接将文件从一个位置传输到另一个位置很重要。根据我的经验，使用 Git 推拉移动临时文件是行不通的。

Answer 3

git gc --aggressive 将清理不必要的文件并优化本地存储库。

您可以通过以下方式验证问题是否已解决：

git fsck --full

Answer 4

我遇到了一个非常相似的问题； broken link from tree 在某些 git 命令上导致错误 fatal: bad tree object。

但是通过运行这些命令修复了它：

修复问题

1. git stash clear（[可选] 只是删除可能由于变基或其他原因而损坏的存储）
2. git reflog expire --expire-unreachable=now --all（删除悬空提交）
3. git gc --prune=now（类似也修剪提交）

检查是否已修复

1. git fsck --full --name-objects（检查完整性，并且不应返回任何悬空提交或坏树）

之后错误消息fatal: bad tree object 消失了！ :tada: