为什么 git checkout 时 git 子模块没有自动更新？

Question

当使用 git checkout 切换分支时，我会假设大多数时候您想要更新子模块。

• 在什么情况下您不想在切换后更新子模块？
• 如果这是通过 git checkout 自动完成的，会出现什么问题？

更新示例：

• 分支 A 在 3852f1 处具有子模块 S
• 分支 B 在 fd72d7 处具有子模块 S

在分支 A 上，git checkout B 将生成分支 B 的工作副本，其子模块 S 在 3852f1 处（带有修改后的 S）。 git 子模块更新将在 fd72d7 处签出 S。

Answer 1

git checkout --recurse-submodules 已添加到 git 2.13

发行说明中提到了这一点：https://github.com/git/git/commit/e1104a5ee539408b 81566066aaa6963cb87d5cd6#diff-c24776ff22455a30fbb78e378b7df0b0R139

submodule.recurse< /code> 选项已添加到 git 2.14

设置为：

git config --global submodule.recurse true

man git-config 说：

指定默认情况下命令是否递归到子模块中。这适用于所有具有 --recurse-submodules 选项的命令。默认为 false。

我觉得默认情况下不更新模块是一种不好的 Git 默认行为，它违背了大多数用户的期望并限制了子模块的采用，我真的希望开发人员能够改变它。

submodule.recurse 使 git fetch 每次都获取所有子模块

这使得该选项基本上慢得无法使用，因为即使子模块启动时也会发生获取迄今为止，它尝试从这些子模块获取分支更新。

我做了很多抓取工作来查看同事的提交，所以我必须经常抓取。与顶级存储库相比，子模块的移动速度往往要慢得多，因此没有必要一直获取它们。

所以现在我坚持使用 Bash 函数解决方法：

gco() { git checkout --recurse-submodules "$@" }

这个解决方法并不完美，因为还有其他命令可以更改提交，例如 git rebase ，因此您最终必须定义多个别名。我现在没有更好的解决方案：

gsuu() {
  git submodule sync --recursive &>/dev/null
  git submodule update --init --recursive --progress "$@"
}
grb() {
  git rebase "$@"
  gsuu
}

Answer 2

我认为子模块不自动更新是符合Git的发展目标的。 Git 旨在以分布式模式工作，并且不假定您甚至能够连接到非本地存储库，除非您明确告诉它。当这样想时，Git 不自动刷新子模块将是预期的行为。

话虽这么说，如果您知道您总是希望拉入这些子模块，并且您知道您永远不会将这些子模块分支到另一个本地存储库，那么如果您在之后自动刷新它们，那么它不应该破坏任何东西结帐。

Answer 3

在 Git 2.27（2020 年第 2 季度）中，“--recurse-submodules”选项得到了更好的记录。

请参阅提交 acbfae3、提交 4da9e99, 提交d09bc51，提交b3cec57，提交 dd0cb7d（2020 年 4 月 6 日），作者：达米恩·罗伯特 (damiens-robert)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 cc908db，2020 年 4 月 28 日）}

doc：--recurse -submodules 主要适用于活动子模块

^{签字人：Damien Robert
帮助者：Philippe Blain}

文档引用了“初始化”或“填充”子模块，以解释哪些子模块受“--recurse-submodules”影响，但这里真正的术语是“活动'子模块。相应地更新文档。

一些术语：

• Active 在 gitsubmodules(7) 中定义 ，它只涉及配置变量 'submodule.active'、'submodule..active' 和 'submodule..url '。
  函数 submodule.c::is_submodule_active< /a> 检查子模块是否处于活动状态。




• 已填充表示子模块的工作树存在（并且 gitfile 正确指向子模块存储库），即超级项目是使用 --recurse-submodules 克隆的，或者用户运行 git submodule update --init，或 git submodule init [] 和 git 子模块更新 [] 分别填充子模块工作树。
  这里不涉及上面的3个配置变量。
• 初始化（至少在本补丁涉及的手册页上下文中）表示“已填充”和“活动”，如上面所定义，即[git submodule update --init](https://git-scm.com/docs/git-submodule) 确实如此。

--recurse-submodules 选项主要影响活动子模块。

git fetch 是一个例外，该选项会影响已填充的子模块。
因此，在 git pull --recurse-submodules 中，提取会影响已填充的子模块，但生成的工作树更新仅影响活动子模块。

在git-pull的文档中，让我们区分影响填充子模块的获取部分和仅影响活动子模块的工作树更新。

---

在 Git 2.33（2021 年第 3 季度）中，submodule.recurse 的文档更加清晰：

请参阅 提交 878b399（2021 年 7 月 16 日），作者：Philippe Blain (phil-blain)。
（由 Junio C Hamano -- gitster -- 合并于 提交 c018818，2021 年 8 月 2 日）

doc：澄清“子模块”的描述。递归'

^{签字人：Philippe Blain}

“submodule.recurse”的文档以“指定命令是否默认递归到子模块”开头。
并非所有具有“--recurse-submodules”选项的命令都是如此。
例如， 'git pull --recurse -submodules'^(man) 不运行 'git pull'^(man) 在每个子模块中，而是运行 'git 子模块更新 --recursive'^(man) 以便拉取后的子模块工作树与记录的提交匹配在超级项目中。

通过简单说明它启用了“--recurse-submodules”来澄清这一点。

请注意，此设置与“fetch.recurseSubmodules”和“push.recurseSubmodules”交互的方式（可以具有除 true 或 false 之外的其他值）已记录在案由于 4da9e99 （“doc：更准确地说（ fetch|push).recurseSubmodules"，2020-04-06，Git v2.27.0-rc0 -- 合并 第 4 批）。

git config 现在包含在其 手册页：

一个布尔值，指示命令是否应默认启用 --recurse-submodules 选项。
适用于所有支持此选项的命令。