Git浅层子模块 [英] Git shallow submodules

问题描述

有可能有浅的子模块吗？我有一个有多个子模块的超级项目，每个子模块都有很长的历史，所以它不必要的拖大了所有的历史。

我发现的所有内容都是这个没有答案的线程。

我应该只是 hack git-submodule 来实现这一点？

解决方案

即将推出的 git1.8.4（2013年7月）：

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

（并且git 2.10 Q3 2016允许使用 git config -f .gitmodules子模块记录<>< name> .shallow true 。

看到这个答案的结尾）

见< A HREF = https://github.com/git/git/commit/275cd184d52b5b81cb89e4ec33e540fb2ae61c1f 的rel = noreferrer>提交275cd184d52b5b81cb89e4ec33e540fb2ae61c1f ：

将 - depth 选项添加到git submodule的add和update命令中，然后将其传递给clone命令。当子模块非常庞大，并且除了最新的提交之外，对于其他任何东西都不感兴趣。

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

签名：Fredrik Gustafsson < [e-mail]>

Acked-by：Jens Lehmann < [e-mail]>

这意味着这可以工作：

  git submodule add --depth 1  - 存储路径
 git子模块update --depth  -  [< path> ...] 
  

有：

   - 深度:: 
  

此选项对于 add 和 update 命令。

创建一个浅克隆，其历史记录截断为指定的修订版本数量。

---

atwyman 增加在评论：

据我可以告诉这个选项isn不适用于非紧密跟踪 master 的子模块。如果您设置了深度1，那么子模块更新只有在您需要的子模块提交是最新的主设备时才会成功。 否则，您将获得<致命：引用不是树。

确实如此。

也就是说，直到git 2.8（2016年3月）。在2.8版本中，即使SHA1可以直接从其中一个远程回购HEAD获得，子模块更新--depth 也有一次成功的机会。

请参阅提交fb43e31 （2016年2月24日）由< href =https://github.com/stefanbeller =noreferrer> Stefan Beller（ stefanbeller ）。

帮助： Junio C Hamano（ gitster ）。< br>
^{（由 Junio C Hamano - gitster 提交9671a76 ，2016年2月26日）}
$ b

子模块：通过直接读取sha1来获取所需的sha1更难

在审查还会更新Ge中子模块的更改时rrit，一个常见的审查实践是下载并在本地挑选补丁来测试它。

然而，当在本地测试时，' git子模块更新'可能无法获取正确的子模块sha1，因为子模块中的相应提交尚未成为项目历史记录的一部分，但也仅仅是一个建议的更改。

如果 $ sha1 不是默认获取的一部分，我们会直接获取 $ sha1 。。然而，有些服务器不支持sha1直接获取，这导致 git-fetch 快速失败。

我们可以在这里失败，因为仍然缺少sha1会导致结账阶段晚些时候失败，所以失败在这里是我们可以得到的好。





---

MVG 指出评价来提交fb43e31 （git 2.9，2016年2月）

在我看来，提交fb43e31 请求丢失由SHA1 ID提交，因此 uploadpack.allowReachableSHA1InWant 和 uploadpack.allowTipSHA1InWant 服务器上的设置可能会影响这是否工作。

我写了一个今天发布到git列表，指出如何使用浅子模块在某些场景下更好地工作，即如果提交也是标记。

让我们拭目以待。

我想这是为什么fb43e31在获取默认分支后为特定SHA1提取回退的原因。
尽管如此，在 - 深度1的情况下，我认为提早放弃是有意义的：如果列出的参考文献都不匹配请求的文献，并且服务器不支持SHA1请求，那么在那里在获取任何东西时都没有意义，因为我们无论如何都无法满足子模块要求。

---

2016年8月更新（3年后）

使用Git 2.10（2016年第3季度），您将可以执行

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

有关更多信息，请参见不超重的Git子模块。

---

Git 2.13（Q2 2017）会添加提交8d3047c （2017年4月19日）由塞巴斯蒂安Schuberth（ sschuberth ）。

^{（由塞巴斯蒂安Schuberth - sschuberth - 在 commit 8d3047c ，2017年4月20日）}

此子模块的克隆将按照一个浅的克隆（历史深度为1）

然而， Ciro Santilli 增加了在评论中（以及在他的回答中的详细信息）

shallow = true on .gitmodules 只影响使用 - recurse-submodules 的远程HEAD跟踪的引用，甚至如果你还在 .gitmodules 上放置了 branch = mybranch 。




Is it possible to have shallow submodules? I have a superproject with several submodules, each with a long history, so it gets unnecessarily big dragging all that history.

All I have found is this unanswered thread.

Should I just hack git-submodule to implement this?

解决方案

New in the upcoming git1.8.4 (July 2013):

"git submodule update" can optionally clone the submodule repositories shallowly.

(And git 2.10 Q3 2016 allows to record that with git config -f .gitmodules submodule.<name>.shallow true.
See the end of this answer)

See commit 275cd184d52b5b81cb89e4ec33e540fb2ae61c1f:

Add the --depth option to the add and update commands of "git submodule", which is then passed on to the clone command. This is useful when the submodule(s) are huge and you're not really interested in anything but the latest commit.

Tests are added and some indention adjustments were made to conform to the rest of the testfile on "submodule update can handle symbolic links in pwd".

Signed-off-by: Fredrik Gustafsson <[e-mail]>
Acked-by: Jens Lehmann <[e-mail]>

That means this works:

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

With:

--depth::

This option is valid for add and update commands.
Create a 'shallow' clone with a history truncated to the specified number of revisions.

---

atwyman adds in the comments:

As far as I can tell this option isn't usable for submodules which don't track master very closely. If you set depth 1, then submodule update can only ever succeed if the submodule commit you want is the latest master. Otherwise you get "fatal: reference is not a tree".

That is true.
That is, until git 2.8 (March 2016). With 2.8, the submodule update --depth has one more chance to succeed, even if the SHA1 is directly reachable from one of the remote repo HEADs.

See commit fb43e31 (24 Feb 2016) by Stefan Beller (stefanbeller).
Helped-by: Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit 9671a76, 26 Feb 2016)}

submodule: try harder to fetch needed sha1 by direct fetching sha1

When reviewing a change that also updates a submodule in Gerrit, a common review practice is to download and cherry-pick the patch locally to test it.
However when testing it locally, the 'git submodule update' may fail fetching the correct submodule sha1 as the corresponding commit in the submodule is not yet part of the project history, but also just a proposed change.

If $sha1 was not part of the default fetch, we try to fetch the $sha1 directly. Some servers however do not support direct fetch by sha1, which leads git-fetch to fail quickly.
We can fail ourselves here as the still missing sha1 would lead to a failure later in the checkout stage anyway, so failing here is as good as we can get.

---

MVG points out in the comments to commit fb43e31 (git 2.9, Feb 2016)

It would seem to me that commit fb43e31 requests the missing commit by SHA1 id, so the uploadpack.allowReachableSHA1InWant and uploadpack.allowTipSHA1InWant settings on the server will probably affect whether this works.
I wrote a post to the git list today, pointing out how the use of shallow submodules could be made to work better for some scenarios, namely if the commit is also a tag.
Let's wait and see.

I guess this is a reason why fb43e31 made the fetch for a specific SHA1 a fallback after the fetch for the default branch.
Nevertheless, in case of "--depth 1" I think it would make sense to abort early: if none of the listed refs matches the requested one, and asking by SHA1 isn't supported by the server, then there is no point in fetching anything, since we won't be able to satisfy the submodule requirement either way.

---

Update August 2016 (3 years later)

With Git 2.10 (Q3 2016), you will be able to do

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

See "Git submodule without extra weight" for more.

---

Git 2.13 (Q2 2017) do add in commit 8d3047c (19 Apr 2017) by Sebastian Schuberth (sschuberth).
^{(Merged by Sebastian Schuberth -- sschuberth -- in commit 8d3047c, 20 Apr 2017)}

a clone of this submodule will be performed as a shallow clone (with a history depth of 1)

However, Ciro Santilli adds in the comments (and details in his answer)

shallow = true on .gitmodules only affects the reference tracked by the HEAD of the remote when using --recurse-submodules, even if the target commit is pointed to by a branch, and even if you put branch = mybranch on the .gitmodules as well.

这篇关于Git浅层子模块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！