【发布时间】:2019-06-28 21:49:39
【问题描述】:
我有多个单独的 git 存储库,其中没有子模块。任务是组装这些存储库的分层树,并使用它在用户之间共享。这对于“subtree”或“subrepo”方案来说是微不足道的,但它似乎不适用于“submodules”。尝试子模块的原因是 nfs 系统上的 git 性能缓慢。在我的情况下,结帐需要 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: 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 来做到这一点。
因此,所需的方案似乎不起作用。有办法解决吗?
【问题讨论】:
-
由于管理子模块的痛苦,我们很久以前就放弃了子模块。在我看来,您可以通过发布包含一系列
git clone命令的脚本来提供相同的功能,也许可以单独选择。 -
@paxdiablo 谢谢,它尝试过并拒绝了这个想法,因为它太不稳定了。它必须依赖分层的 .gitignores 并且需要大量的脚本。拥有庞大的客户群,它不会运作良好。所以,我希望子模块能让它更易于管理。
标签: git git-submodules