“git submodule foreach git pull origin master”与“git submodule foreach git pull origin master”有什么不同？和“git pull origin master --recurse-submodules” [英] What is the difference between "git submodule foreach git pull origin master" and "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 的要点是什么？我对它实际上试图做什么感到有点困惑，Google对我的发现有点神秘。我想也许你聪明的人会有一个更简单的解释。

所有子模块都会提交，而不仅仅是像master一样提取一个特定的分支，原因在于以下两个提交中详细说明的原因：

（请注意，在Git 2.11中修复了一个错误，请参阅此答案的结尾处）

对于 git pull ，这个选项已经在（ commit 7dce19d，Nov. 2010，git 1.7.4-rc0）：

fetch / pull ：添加 - 递归子模块选项

直到现在您必须调用 git子模块更新（不带 -N | --no-fetch 选项）或类似于 git submodule foreach git fetch 来获取新提交从他们的遥控器安装子模块。 $ b

这可能导致
输出中的（提交不存在）消息 git diff --submodule （它被 git gui 和 gitk ）在
之后获取或拉超级项目中的新提交，并且是
实现子模块的递归结帐的障碍。

也是 git submodule update 在断开连接时无法获取更改，因此在断开连接之前忘记获取子模块更改非常容易，以后才发现它们是必需的。

此修补程序添加 - recurse子模块选项以递归方式从<$ c中配置的URL中获取每个已填充的子模块
code> git fetch 或<$ c $期间的
子模块的$ c> .git / config c> git pull 在
超级项目中。子模块路径取自索引。

---

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

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

为了能够访问由
超级项目引用的所有已填充子模块的提交，只需让 git fetch 当在超级项目记录中获取的新提交新增
提交时，递归到
子模块中。
$ b

使用 - 子模块选项改为 git diff （这就是 git gui 和
gitk do since 1.6.6），因为可以访问创建
描述性输出所需的所有子模块提交。 另外合并子模块提交（在1.7.3中添加）取决于存在问题的子模块提交。

最后但并非最不重要的这使得在使用
子模块时可以进行断开连接操作，因为成功执行 git子模块更新-N 将自动获取。

所以我们选择这种模式作为抓取和拉取的默认模式。

---

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

第一个应该拉动，不仅仅是抓取，而且相当于第二个。也许这是一个参数订单问题：

  git pull --recurse-submodules原点大师
  

但是，对于给定的分支来说，更新子模块并不是一种推荐的方式：请参阅以下部分。

---

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

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

然后一个简单的 git submodule update --remote --recursive 就足够了。

抓取/拉取的分支记录在父回购库中（在 .gitmodules 文件中），所以你甚至不必记住你希望你的子模块更新哪个分支。

---

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

拥有一个子模块，其 .git 存储库以某种方式损坏了
引起了一些永久递归到子模块的命令。

请参阅 commit 10f5c52 （2016年9月1日）作者： Junio C Hamano（ gitster ）。

^{（由 Junio C Hamano - gitster - in commit 293c232 ，2016年9月12日）}

I have a dotfiles repository where all my vim plugins are stored as submodules so they are easy to update when they have changes. I thought these two commands did the same thing, but I noticed this must not be the case.

I knew I had updates to pull down in several submodules so I ran git pull origin master --recurse-submodules from the root of the parent repository. It appeared to iterate over each submodule, but only fetch updates from their origin repositories.

When I ran git submodule foreach git pull origin master then it actually ran git pull origin master within each repository, doing both the fetch and the merge.

What is the point of using --recurse-submodules? I'm a little confused about what it's actually trying to do and Google was a bit cryptic with what I found. I thought maybe you smart folks would have a simpler explanation.

解决方案

That option is mainly for fetching all the submodule commits, not just pulling one specific branch like master, for reasons detailed in the two following commits:
(note there is a bug fixed in Git 2.11, see at the end of this answer)

For git pull, this option has been introduced in (commit 7dce19d, Nov. 2010, git 1.7.4-rc0):

fetch/pull: Add the --recurse-submodules option

Until now you had to call "git submodule update" (without -N|--no-fetch option) or something like "git submodule foreach git fetch" to fetch new commits in populated submodules from their remote.

This could lead to "(commits not present)" messages in the output of "git diff --submodule" (which is used by "git gui" and "gitk") after fetching or pulling new commits in the superproject and is an obstacle for implementing recursive checkout of submodules.
Also "git submodule update" cannot fetch changes when disconnected, so it was very easy to forget to fetch the submodule changes before disconnecting only to discover later that they are needed.

This patch adds the "--recurse-submodules" option to recursively fetch each populated submodule from the url configured in the .git/config of the submodule at the end of each "git fetch" or during "git pull" in the superproject. The submodule paths are taken from the index.

---

Commit 88a2197 (March 2011, git 1.7.5-rc1) explains a bit more:

fetch/pull: recurse into submodules when necessary

To be able to access all commits of populated submodules referenced by the superproject, it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it.

• Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed.
• Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work.
• Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically.

So we choose this mode as the default for fetch and pull.

---

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

The first one should pull, not just fetch, and be equivalent to the second one. Maybe this is a parameter order issue:

git pull --recurse-submodules origin master 

However, it is not the recommended way to update submodule for a given branch: see the following section.

---

Note that the right way to actually pull from master would be to register the master branch to the submodule, making that submodule tracking master:

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

Then a simple git submodule update --remote --recursive would be enough.
And the branch to fetch/pull is recorded in the parent repo (in the .gitmodules file), so you don't even have to remember which branch you want your submodule to update against.

---

Update Git 2.11 (Q4 2011)

Having a submodule whose ".git" repository is somehow corrupt caused a few commands that recurse into submodules loop forever.

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

这篇关于“git submodule foreach git pull origin master”与“git submodule foreach git pull origin master”有什么不同？和“git pull origin master --recurse-submodules”的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！