git获取失败，返回“0”；致命：git上传包：不是我们的参考a639…“；第二次成功

我们有一个包含各种子模块的git存储库。主repo有一个旧的克隆，在运行

git fetch

时，我们在该克隆上重复出现以下错误：

fatal: remote error: upload-pack: not our ref a63912a948cf1ce4c700c16b3417e89287f61f63
fatal: git upload-pack: not our ref a63912a948cf1ce4c700c16b3417e89287f61f63

在此之后第二次运行

git fetch

时，错误消失

我目前的假设是，旧克隆（或正在获取的某个分支）包含对子模块中提交的引用，这些子模块由于任何原因（rebases？）已从源代码中消失。我知道这可能发生，但我如何才能找到特定的悬挂引用，以便修复它

旧的克隆位于我们用于设置测试的基础映像中，因此我可以完美地重现错误，即使它在每秒钟的尝试中都消失了。然而，我不愿意仅仅通过使用

git-fetch | | git-fetch

或类似的黑客来忽略这个问题

那么，我如何找出主回购协议中的哪个提交引用了缺失的ref

a63912…

---

更一般地说，有没有一种方法可以对回购协议执行完整性检查，从而提前发现这些错误？

Alex，你找到这个方法了吗？我遇到了同样的问题。在我的例子中，原因是获取的分支临时将子模块指向从未推送到子模块存储库的提交。一种解决方法似乎是首先使用

——无递归子模块

，然后使用

——递归子模块

，尽管这比只尝试两次好不了多少。我相信第二次取回成功的原因是父回购的取回实际上已经完成，因此在重新运行时它不会遇到无效的ref。如果确实发生了这种情况，那肯定是令人困惑的。嗨@Alex-你成功地解决了这个问题吗？我撞到了同一堵墙。。。