git - 使用嵌套子模块克隆 repo 不起作用

Question

我有多个单独的 git 存储库，其中没有子模块。任务是组装这些存储库的分层树，并使用它在用户之间共享。这对于“subtree”或“subrepo”方案来说是微不足道的，但它似乎不适用于“submodules”。尝试子模块的原因是 nfs 系统上的 git 性能缓慢。在我的情况下， checkout 需要超过 2 小时

我正在尝试创建一个包含子模块的共享仓库。到目前为止，第一次克隆尝试失败了。这是测试用例:

 mkdir m1 ; cd m1 ; git init ; date > a.txt ; git add --all ; git commit -m added ; cd -
 mkdir m2 ; cd m2 ; git init ; date > b.txt ; git add --all ; git commit -m added ; cd -
 mkdir m3 ; cd m3 ; git init ; date > c.txt ; git add --all ; git commit -m added ; cd -
 mkdir msub; cd msub; git init; date > d.txt; git add --all; git commit -m added;
 git submodule add `realpath ../m1` m1
 cd m1
 git submodule add `realpath ../../m2` m2
 git submodule add `realpath ../../m3` m3
 git commit -m 'added submodules'
 cd ..
 git commit -m 'added a submodule'
 cd ..
 git clone --recursive msub msub1

结果，它创建了带有单个顶级子模块 (m1) 的 msub1。

在其他情况下，在克隆第一个子模块后，我遇到了与此类似的 fatal error 。

fatal: git upload-pack: not our ref 89434ad65c1e697bfa311cd0260dfe1997985e65
fatal: remote error: upload-pack: not our ref 89434ad65c1e697bfa311cd0260dfe1997985e65
Fetched in submodule path 'soc', but it did not contain 89434ad65c1e697bfa311cd0260dfe1997985e65. Direct fetching of that commit failed.

我尝试直接将子模块添加到“m1”，它似乎改善了这种情况，但我无法使用真正的 repos 来做到这一点。

因此，所需的方案似乎不起作用。有没有办法解决它？

Answer 1

“not our ref”响应通常意味着您的服务器配置为限制通过 ID 直接获取对象，并且没有合适的引用允许获取该对象。

Git 提供了三个选项来控制您是否可以获取任意对象 ID:一个允许获取 Git 有权访问的任意对象，一个允许从引用中获取任何可访问的对象，以及另外一个允许从 stash 引用中获取可访问的对象.大多数服务器提供商选择禁用其中的一个或多个，这通常意味着您只能在非 stash 引用(即分支或标签)指向它时请求对象 ID。

“not our ref”消息意味着您正在尝试按对象 ID 获取对象，该对象 ID 用于子模块，但由于上述原因服务器不允许这样做。如果您使用的是 Bitbucket Server 的 ref 缓存，这也可能意味着服务器缓存了陈旧的数据；在这种情况下，如果您需要工作，您应该禁用 ref 缓存。

您可以做几件事。如果您需要检查任意修订的能力，您可以创建一个指向它的分支。或者，如果您的子模块不需要特定版本，而只需要最新的分支，您可以设置 submodule.<name>.branch选项(参见 man gitmodules )，然后您将始终查看最新的分支。如果您使用的是自托管服务器，您可以设置 uploadpack.allowAnySHA1InWant为真。最后，您可以手动获取子模块(可能使用 git submodule foreach )，它通常具有您想要的修订版。