如何制作浅git子模块？

Question

是否有可能有浅子模块？我有一个包含多个子模块的超级项目,每个子模块都有很长的历史记录,所以它拖延了所有历史记录.

我找到的只是这个没有答案的线索.

我应该破解git-submodule来实现这个吗？

Answer 1

即将发布的git1.8.4(2013年7月)中的新内容:

" git submodule update"可以选择性地克隆子模块存储库.

(并且git 2.10 2016年第3季度允许记录该内容git config -f .gitmodules submodule.<name>.shallow true.
请参阅此答案的结尾)

见commit 275cd184d52b5b81cb89e4ec33e540fb2ae61c1f:

将--depth选项添加到"git submodule"的add和update命令,然后将其传递给clone命令.当子模块很大并且除了最新的提交之外你什么都不感兴趣时​​,这很有用.

添加测试并进行一些缩进调整以符合"子模块更新可以处理pwd中的符号链接"的测试文件的其余部分.

签名:Fredrik Gustafsson <iveqy@iveqy.com>
Acked-by:Jens Lehmann<Jens.Lehmann@web.de>

这意味着这有效:

git submodule add --depth 1 -- repository path
git submodule update --depth -- [<path>...]

附:

--depth::

此选项是有效的add和update命令.
创建一个"浅"克隆,其历史记录被截断为指定的修订数.

atwyman 在评论中补充道:

据我所知,这个选项不适用于不能master非常密切跟踪的子模块.如果设置深度1,那么submodule update只有在您想要的子模块提交是最新的主设备时才能成功. 否则你得到" fatal: reference is not a tree".

那是真实的.
也就是说,直到git 2.8(2016年3月).使用2.8,submodule update --depth即使SHA1可以从其中一个远程repo HEAD直接访问,也有一次成功的机会.

请参阅Stefan Beller()提交fb43e31(2016年2月24日). 帮助:Junio C Hamano().^{(由Junio C Hamano合并- -在提交9671a76,2016年2月26日)}stefanbeller
gitster
gitster

子模块:通过直接获取sha1来更加努力地获取所需的sha1

在查看同时更新Gerrit中的子模块的更改时,常见的审查做法是在本地下载并挑选补丁以对其进行测试.
但是,在本地测试时,' git submodule update'可能无法获取正确的子模块sha1,因为子模块中的相应提交还不是项目历史记录的一部分,而且只是建议的更改.

如果$sha1不是默认提取的一部分,我们尝试$sha1直接获取.但是,某些服务器不支持sha1直接获取,这会导致git-fetch快速失败.
我们可以在这里失败,因为仍然缺少sha1会在结账阶段导致失败,所以在这里失败就像我们能得到的一样好.

MVG指出,在评论中,以提交fb43e31(GIT 2.9 2月2016)

在我看来,提交fb43e31通过SHA1 id请求丢失的提交,因此服务器上的uploadpack.allowReachableSHA1InWant和uploadpack.allowTipSHA1InWant设置可能会影响它是否有效.
我今天在git列表中写了一篇文章,指出如何使用浅子模块在某些情况下更好地工作,即如果提交也是一个标记.
让我们等着看.

我想这就是为什么fb43e31在获取默认分支后对特定SHA1进行回退的原因.
然而,在"--depth 1"的情况下,我认为提前中止是有意义的:如果列出的引用中没有一个匹配所请求的引用,并且服务器不支持SHA1请求,则没有任何意义.获取任何东西,因为无论如何我们都无法满足子模块的要求.

2016年8月更新(3年后)

使用Git 2.10(2016年第3季度),您将能够做到

 git config -f .gitmodules submodule.<name>.shallow true

有关更多信息,请参阅" 没有额外重量的Git子模块 ".

Git 2.13(2017年第2季度)在Sebastian Schuberth()中添加提交8d3047c(2017年4月19日).^{(由Sebastian Schuberth合并- -在提交8d3047c,2017年4月20日)}sschuberth
sschuberth

该子模块的克隆将作为浅层克隆执行(历史深度为1)

但是,Ciro Santilli 在评论中添加了(并在他的回答中详细说明)

shallow = trueon .gitmodules仅在使用时影响远程HEAD跟踪的引用--recurse-submodules,即使目标提交由分支指向,即使您也branch = mybranch使用了.gitmodules它.

Git 2.20(Q8 2018)改进了子模块支持,该子模块支持已更新为从工作树中缺少文件HEAD:.gitmodules时的blob读取.gitmodules.

参见提交2b1257e,提交76e9bdc(2018年10月25日),并提交b5c259f,提交23dd8f5,提交b2faad4,提交2502ffc,提交996df4d,提交d1b13df,提交45f5ef3,提交bcbc780(2018年10月5日),由Antonio Ospite(ao2)提交.
^{(由Junio C gitsterHamano合并- -在提交abb4824,2018年11月13日)}

submodule:.gitmodules当它不在工作树中时支持阅读

如果.gitmodules文件在工作树中不可用,请尝试使用索引和当前分支中的内容.
这包括文件是存储库的一部分但由于某种原因未检出的情况,例如由于稀疏检出.

这使得可以使用至少" git submodule这"命令读取的gitmodules不完全填充工作树配置文件.

写入.gitmodules仍然需要检出文件,因此在调用之前检查该文件config_set_in_gitmodules_file_gently.

同时添加类似的检查git-submodule.sh::cmd_add()以预测" git submodule add"命令在.gitmodules不可安全写入时最终失败; 这可以防止命令将存储库置于虚假状态(例如,子模块存储库已克隆但.gitmodules由于config_set_in_gitmodules_file_gently失败而未更新).

此外,由于config_from_gitmodules()现在访问全局对象存储,因此必须保护调用该函数的所有代码路径,以防止对全局对象存储的并发访问.
目前这只发生在builtin/grep.c::grep_submodules(),所以 grep_read_lock()在调用涉及的代码之前调用config_from_gitmodules().

注意:有一种罕见的情况是这个新功能还没有正常工作:嵌套的子模块没有.gitmodules在他们的工作树中.

Answer 2

Git 2.9.0直接支持submodules浅克隆,所以现在你可以调用:

git clone url://to/source/repository --recursive --shallow-submodules

Answer 3

按照Ryan的回答,我能够想出这个简单的脚本,它遍历所有的子模块和浅层克隆:

#!/bin/bash
git submodule init
for i in $(git submodule | sed -e 's/.* //'); do
    spath=$(git config -f .gitmodules --get submodule.$i.path)
    surl=$(git config -f .gitmodules --get submodule.$i.url)
    git clone --depth 1 $surl $spath
done
git submodule update

Answer 4

通过git-submodule"source"读取,看起来git submodule add可以处理已经存在其存储库的子模块.在这种情况下...

$ git clone $remote1 $repo
$ cd $repo
$ git clone --depth 5 $remotesub1 $sub1
$ git submodule add $remotesub1 $sub1
#repeat as necessary...

您需要确保所需的提交位于子模块仓库中,因此请确保设置适当的--depth.

编辑:您可以使用多个手动子模块克隆,然后进行单次更新:

$ git clone $remote1 $repo
$ cd $repo
$ git clone --depth 5 $remotesub1 $sub1
#repeat as necessary...
$ git submodule update

Answer 5

从Git 2.14.1开始的错误/意外/令人讨厌行为的摘要

1. shallow = true在.gitmodules仅影响git clone --recurse-submodules，如果HEAD远程子模块指向必需的承诺，即使目标承诺是由一个分支指向，即使你把branch = mybranch上.gitmodules也是如此。

   本地测试脚本。在GitHub 2017-11上的行为相同，HEAD由默认分支回购设置控制：

   git clone --recurse-submodules https://github.com/cirosantilli/test-shallow-submodule-top-branch-shallow
   cd test-shallow-submodule-top-branch-shallow/mod
   git log
   # Multiple commits, not shallow.
   

2. git clone --recurse-submodules --shallow-submodules如果分支或标记均未通过消息引用提交，则失败error: Server does not allow request for unadvertised object。

   本地测试脚本。在GitHub上的行为相同：

   git clone --recurse-submodules --shallow-submodules https://github.com/cirosantilli/test-shallow-submodule-top-sha
   # error
   

   我还在邮件列表上问过：https : //marc.info/? l =git&m=151863590026582&w=2，回复是：

   从理论上讲，这应该很容易。:)

   不幸的是，实际上没有那么多。这是因为克隆只会获得分支的最新提示（通常是主节点）。克隆中没有机制来指定所需的确切sha1。

   有线协议支持询问确切的sha1，因此应予以覆盖。（注意：仅当服务器操作员启用github没有AFAICT的uploadpack.allowReachableSHA1InWant时才有效）

   git-fetch允许获取任意sha1，因此，一种变通办法是，您可以通过使用“ git submodule update”在递归克隆之后运行获取，因为它将在初始克隆之后使用获取。

TODO测试：allowReachableSHA1InWant。