如何修复从一棵树到另一棵树的git错误断开的链接？

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

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-gc——激进的

将清理不必要的文件并优化本地存储库

您可以使用git 2.10（2016年第3季度）验证git fsck--full解决了问题，您可以了解更多关于这些断开链接的来源的信息

git fsck --name-objects

参见，，（2016年7月17日）作者 （于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...

树b5eb6ff中的链接已断开。。。（参考文献37:）
要blob ec5cf80。。。

如果这些断开的链接不是来自本地存储，而是来自远程回购，。
另见“”

---

在Git2.31（2021年第1季度）中，fix“”（）显然没有被任何有足够动机报告破损的人使用过

参见（2021年2月10日）by.
（于2021年2月17日合并）

：解析生成编号时要更加小心 签字人：Johannes Schindelin

在（

fsck_walk（）

：可选地命名移动中的对象，2016-07-17，Git v2.10.0-rc0——在中列出）

（fsck_walk（）

：可选地命名移动中的对象，2016-07-17），

fsck

机器学会了可选地命名对象，以便更容易地看到存储库的哪个部分处于不良状态，比如，当对象丢失时

为了节省复杂性，此机制使用解析器来确定给定提交名称的父级名称：解析任何

~

后缀，父级名称由前缀和

~

组成

但是，此解析器有一个错误：如果它发现一个后缀

不是

~

，它会将空字符串误认为前缀，将

误认为生成号。
换句话说，它将生成一个

~

格式的名称

让我们来解决这个问题

---

对于我来说，解决这个“断开链接”错误的方法是下面列出的答案，回答了一个关于如何解决“找不到”错误的问题：

正如Adam所说，从另一个存储库/克隆恢复对象

在“完整”git数据库上：

git cat文件-p A47058D09B4CA436D65609758A9DBA5235A75BD>临时文件

在接收端：

git散列对象-w tempfile

---

一个重要的补充是，在步骤1和步骤2之间，将文件从一个位置直接传输到另一个位置非常重要。根据我的经验，使用GIT push and pull移动临时文件是不起作用的。

对于GIT 2.10（2016年第3季度），

GIT fsck--name objects

会有所帮助。请参阅当存在断开的链接时，此操作不起作用：

错误：无法读取xxxxxxxxx”

，

致命：无法遍历提交YYYYYY的父级

，

错误：无法运行重新打包