Git 在哪里存储子模块提交的 SHA1？

发布于 2024-10-17 22:28:57 字数 385 浏览 2 评论 0 原文

我知道，当您将子模块添加到 git 存储库时，它会跟踪其 sha1 引用的该子模块的特定提交。

我正在尝试查找此 sha1 值的存储位置。

.gitmodules 和 .git/config 文件仅显示子模块的路径，但不显示提交的 sha1。

git-submodule(1) 参考仅涉及 gitlink 条目和 < href="http://www.kernel.org/pub/software/scm/git/docs/gitmodules.html">gitmodules(5) 参考也没有说明这一点。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

浮光之海 2024-10-24 22:28:57

它直接存储在Git的对象数据库中。子模块所在目录的树对象将有一个子模块提交的条目（这就是所谓的“gitlink”）。

尝试执行 git ls-tree master （或者如果子模块位于顶层，则仅执行 git ls-tree master目录）。

回复收藏 0 原文

浅笑轻吟梦一曲 2024-10-24 22:28:57

对象数据库 ($GIT_DIR/objects/ ）存储子模块树对象的位置最近正在不断发展：

随着 Git 2.34（2021 年第 4 季度），生成“git grep"^(man) 递归到子模块已更新为从添加子模块对象存储迁移为备用对象存储”机制（这是次优的）。

请参阅提交 18a2f66、提交 e3e8bf0, 提交0693806，提交 dd45471，提交 78ca584, 提交 50d92b5，提交 8d33c3a，提交 a35e03d（2021 年 8 月 16 日），作者：Jonathan Tan (jhowtan)。
^{（由 Junio C Hamano -- gitster -- 合并于提交 11e5d0a，2021 年 9 月 20 日）}

子模块：延迟添加子模块ODB作为备用

^{签字人：Jonathan Tan}
^{审阅者：Emily Shaffer}
^{审阅者：Matheus Tavares}

仅在首次访问不在 the_repository 中的对象时，才教导 Git 将子模块 ODB 添加为 the_repository 的对象存储的替代项，而不是在 add_submodule_odb 时() 被调用。

这提供了一种从通过替代访问子模块的对象逐渐迁移到通过显式传递其存储库对象来访问子模块的对象的方法。
任何 Git 命令都可以声明它可以通过调用 add_submodule_odb() 来访问子模块对象（就像现在一样），但子模块 ODB 本身不会在需要时添加，因此单个命令和/或组合参数可以一一迁移。

[显式存储库对象传递的优点是代码清晰（清楚地读取对象来自哪个存储库）、性能（每当从任何存储库访问对象时都不需要线性搜索所有子模块 ODB，无论是超级项目还是子模块），以及未来功能的可能性，例如部分克隆子模块（目前这是不可能的，因为如果对象丢失，我们不知道要延迟提取到哪个存储库）。]

此提交还引入了一个环境变量，测试可能会设置该环境变量以使替代项的实际注册变得致命，以证明其代码路径不需要此注册。

The object database ($GIT_DIR/objects/) where the submodule tree object is stored, is evolving recently:

With Git 2.34 (Q4 2021), the code to make "git grep"^(man) recurse into submodules has been updated to migrate away from the add submodules object store as an alternate object store" mechanism (which is suboptimal).

See commit 18a2f66, commit e3e8bf0, commit 0693806, commit dd45471, commit 78ca584, commit 50d92b5, commit 8d33c3a, commit a35e03d (16 Aug 2021) by Jonathan Tan (jhowtan).
^{(Merged by Junio C Hamano -- gitster -- in commit 11e5d0a, 20 Sep 2021)}

submodule: lazily add submodule ODBs as alternates

^{Signed-off-by: Jonathan Tan}
^{Reviewed-by: Emily Shaffer}
^{Reviewed-by: Matheus Tavares}

Teach Git to add submodule ODBs as alternates to the object store of the_repository only upon the first access of an object not in the_repository, and not when add_submodule_odb() is called.

This provides a means of gradually migrating from accessing a submodule's object through alternates to accessing a submodule's object by explicitly passing its repository object.
Any Git command can declare that it might access submodule objects by calling add_submodule_odb() (as they do now), but the submodule ODBs themselves will not be added until needed, so individual commands and/or combinations of arguments can be migrated one by one.

[The advantage of explicit repository-object passing is code clarity (it is clear which repository an object read is from), performance (there is no need to linearly search through all submodule ODBs whenever an object is accessed from any repository, whether superproject or submodule), and the possibility of future features like partial clone submodules (which right now is not possible because if an object is missing, we do not know which repository to lazy-fetch into).]

This commit also introduces an environment variable that a test may set to make the actual registration of alternates fatal, in order to demonstrate that its codepaths do not need this registration.