“git submodule foreach git pull origin master”和“git pull origin master --recurse-submodules”有什么区别

我有一个 dotfiles 存储库，其中所有 vim 插件都存储为子模块，因此在发生更改时很容易更新。我以为这两个命令做了同样的事情，但我注意到事实并非如此。

我知道我有几个子模块需要更新，所以我跑了git pull origin master --recurse-submodules从父存储库的根目录。它似乎迭代每个子模块，但仅从其原始存储库获取更新。

当我跑的时候git submodule foreach git pull origin master然后它实际上运行了git pull origin master在每个存储库中，执行获取和合并。

使用有什么意义--recurse-submodules？我对它实际上想要做什么有点困惑，谷歌对我发现的内容有点神秘。我想也许你们聪明人会有一个更简单的解释。

该选项主要是为了fetching所有子模块提交，而不仅仅是拉取像 master 这样的一个特定分支，原因在以下两个提交中详细说明：
（请注意，Git 2.11 中修复了一个错误，请参阅本答案的末尾）

For git pull，此选项已在 (提交 7dce19d，2010 年 11 月，git 1.7.4-rc0）:

fetch/pull：添加--recurse-submodules option

直到现在你还得打电话“git submodule update“ （没有-N|--no-fetch选项）或类似“git submodule foreach git fetch" 从远程获取已填充子模块中的新提交。

这可能会导致“(commits not present)" 输出中的消息 ”git diff --submodule“（由“使用”git gui" and "gitk“） 后 在超级项目中获取或拉取新的提交，这是一个障碍 实现子模块的递归检出。
Also "git submodule update“断开连接时无法获取更改，因此很容易忘记在断开连接之前获取子模块更改，只是后来才发现需要它们。

该补丁添加了“--recurse-submodules" 递归获取的选项 从配置的 url 中每个填充的子模块.git/config的 每个“末尾的子模块git fetch“或期间”git pull“ 在里面 超级项目。子模块路径取自索引。

提交 88a2197（2011 年 3 月，git 1.7.5-rc1）多解释一下：

fetch/pull：必要时递归到子模块

为了能够访问由引用的填充子模块的所有提交 超级项目，只需让“git fetch“ 递归成 当在超级项目中获取新提交时的子模块记录新 并为此做出承诺。

• 使用“时”时，存在这些提交非常有用--submodule“ 选项 ”git diff"（这就是“git gui" and "gitk“自 1.6.6 起执行），因为创建一个子模块所需的所有子模块提交 可以访问描述性输出。
• Also 合并子模块提交（在 1.7.3 中添加）取决于存在问题的子模块提交是否有效.
• 最后但并非最不重要的这可以在使用时实现断开连接操作 子模块，因为所有人都致力于成功的“git submodule update -N" 将被自动获取。

所以我们选择这种模式作为 fetch 和 pull 的默认模式。

git pull origin master --recurse-submodules 
git submodule foreach git pull origin master

第一个应该拉动，而不仅仅是获取，并且与第二个等效。也许这是一个参数顺序问题：

git pull --recurse-submodules origin master 

但是，这不是更新给定分支的子模块的推荐方法：请参阅以下部分。

请注意，实际从 master 拉取的正确方法是将主分支注册到子模块，使该子模块跟踪主模块：

git config -f .gitmodules submodule.<path>.branch <branch>

然后一个简单的git submodule update --remote --recursive就足够了。
并且要获取/拉取的分支记录在父存储库中（在.gitmodules文件），因此您甚至不必记住您希望子模块更新哪个分支。

更新 Git 2.11（2011 年第 4 季度）

有一个子模块，其“.git“ 存储库不知何故已损坏 导致一些命令永远递归到子模块循环中。

See commit 10f5c52 (01 Sep 2016) by Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit 293c232, 12 Sep 2016)}

This last 2016 commits is expended with With Git 2.21 (Q4 2018): "git fetch --recurse-submodules"^(man) may not fetch the necessary commit that is bound to the superproject, which is getting corrected.

See commit be76c21 (06 Dec 2018), and commit a62387b, commit 26f80cc, commit d5498e0, commit bcd7337, commit 16dd6fe, commit 08a297b, commit 25e3d28, commit 161b1cf (28 Nov 2018) by Stefan Beller (stefanbeller).
^{(Merged by Junio C Hamano -- gitster -- in commit 5d3635d, 29 Jan 2019)}

submodule.c：在子模块 git 目录中获取而不是在工作树中获取

^{Signed-off-by: Stefan Beller}

保留引入的属性10f5c52656 ("submodule：避免自动发现prepare_submodule_repo_env()”，2016-09-01，Git v2.11.0-rc0 --merge列于batch #1），通过固定git子模块的目录。

But... "git fetch"^(man) did not work correctly with nested submodules where the innermost submodule that is not of interest got updated in the upstream, which has been corrected with Git 2.30 (Q1 2021).

See commit 1b7ac4e (12 Nov 2020) by Peter Kaestle (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit d627bf6, 25 Nov 2020)}

submodules：修复了获取非 init subsub-repo 时的回归问题

^{Signed-off-by: Peter Kaestle}

回归已被引入a62387b ("submodule.c: 在子模块 git 目录中获取而不是在工作树中获取", 2018-11-28, Git v2.21.0-rc0 --merge列于batch #4).

它触发的场景是当一个远程存储库在子存储库内有一个子存储库时，如下所示：superproject/middle_repo/inner_repo

A 和 B 都有它的克隆，而 B 没有使用它inner_repo因此没有在他的工作副本中初始化它。

现在 A 提出了一个改变inner_repo并通过middle_repo和超级项目。

Once person A pushed the changes and person B wants to fetch them using "git fetch"^(man) on superproject level, B's git^(man) call will return with error saying:

无法访问子模块'inner_repo' 子模块获取期间出错：> middle_repo

Expectation is that in this case the inner submodule will be recognized as uninitialized subrepository and skipped by the git fetch^(man) command.

这在之前可以正常工作'a62387b ("submodule.c: 在子模块 git 目录中获取而不是在工作树中获取", 2018-11-28, Git v2.21.0-rc0 --merge列于batch #4)'.

从...开始a62387b代码想要评估"is_empty_dir()“ 里面.git/modules对于仅存在于工作树中的目录，当然会提供错误的返回值。

此补丁恢复了以下更改a62387b并引入回归测试。

Warning: An earlier attempt to fix "git fetch --recurse-submodules"^(man) broke another use case; revert it with Git 2.30 (Q1 2021), until a better fix is found.

See commit 7091499 (02 Dec 2020) by Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit f3e5dcd, 03 Dec 2020)}

Revert "submodules：修复了获取非 init subsub-repo 时的回归问题”

This reverts commit 1b7ac4e6d4d490b224f5206af7418ed74e490608 Ralf Thielow reports that "git fetch"^(man) with submodule.recurse set can result in a bogus and infinitely recursive fetching of the same submodule.

With Git 2.30.1 (Q1 2021), "git fetch --recurse-submodules"^(man) fix (second attempt).

See commit 505a276 (09 Dec 2020) by Peter Kaestle (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit c977ff4, 06 Jan 2021)}

submodules：修复了获取非 init subsub-repo 时的回归问题

^{Signed-off-by: Peter Kaestle
CC: Junio C Hamano
CC: Philippe Blain
CC: Ralf Thielow
CC: Eric Sunshine
Reviewed-by: Philippe Blain}

回归已被引入a62387b ("submodule.c: 在子模块 git 目录中获取而不是在工作树中获取", 2018-11-28, Git v2.21.0-rc0 --merge列于batch #4).

它触发的场景是当一个存储库的子模块内有一个子模块时，如下所示：superproject/middle_repo/inner_repo

A 和 B 都有它的克隆，而 B 没有使用它inner_repo因此没有在他的工作副本中初始化它。

现在 A 提出了一个改变inner_repo并通过middle_repo和超级项目。

Once person A pushed the changes and person B wants to fetch them using "git fetch"^(man) at the superproject level, B's git call will return with error saying:

无法访问子模块'inner_repo' 子模块获取期间出错： 中间仓库

期望在这种情况下，内部子模块将被识别为未初始化的子模块并被git fetch命令。

这在之前可以正常工作'a62387b ("submodule.c: 在子模块 git 目录中获取而不是在工作树中获取", 2018-11-28, Git v2.21.0-rc0 --merge列于batch #4)'.

从...开始a62387b代码想要评估"is_empty_dir()“ 里面.git/modules对于仅存在于工作树中的目录，当然会提供错误的返回值。

该补丁可确保is_empty_dir()通过连接实际工作树和未初始化子模块的名称来获取未初始化子模块的正确路径。

修复此回归的第一次尝试是1b7ac4e ("submodules：修复获取非 init subsub-repo 时的回归问题”，2020-11-12，Git v2.30.0-rc0 --merge列于batch #8），通过简单地恢复a62387b，在具有未初始化子模块的超级项目的递归获取的更简单情况下导致子模块获取的无限循环，因此此提交被还原7091499（恢复 ”submodules：修复获取非 init subsub-repo 时的回归问题”，2020-12-02，Git v2.30.0-rc0 --merge列于第 10 批).
为了防止将来出现损坏，还要为此场景添加回归测试。

"git fetch --recurse-submodules from``"^(man) multiple remotes (either from a remote group, or "--all") used to make one extra "git fetch"^(man) in the submodules, which has been corrected with Git 2.37 (Q3 2022).

See commit 0353c68 (16 May 2022) by Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit fa61b77, 25 May 2022)}

fetch：不要从子模块运行冗余提取

^{Reviewed-by: Glen Choo}

When 7dce19d ("fetch/pull：添加--recurse-submodules选项”，2010-11-12，Git v1.7.4-rc0 --merge）引入了“--recurse-submodule”选项，所采取的方法是在所有主要提取之后仅在子模块中执行一次提取（通常可能是从单个远程提取，但也可能是从一组远程提取）遥控器使用fetch_multiple()）成功了。
后来我们添加了“--all”来从所有定义的遥控器中获取数据，这使事情变得更加复杂。

If your project has a submodule, and you try to run "git fetch"^(man) --recurse-submodule --all, you'd see a fetch for the top-level, which invokes another fetch for the submodule, followed by another fetch for the same submodule.
All but the last fetch for the submodule come from a "git fetch --recurse-submodules"^(man) subprocess that is spawned via the fetch_multiple() interface for the remotes, and the last fetch comes from the code at the end.

因为从子模块递归获取是在每次获取顶层时完成的fetch_multiple()，子模块中的最后一次获取是多余的。
只有当fetch_one()与顶层的单个遥控器交互。

当我们这样做时，在处理一组远程时存在一个优化，但当“--all“ 用来。
在前者中，当群体变成一个群体时，而不是产卵”git fetch“ 作为子进程通过fetch_multiple()界面，我们使用普通的fetch_one()代码路径。
递“时也做同样的事”--all”，如果事实证明我们只定义了一个远程。