将 git 的 submodule.recurse 配置选项设置为 true 有什么缺点？
What are the drawbacks to setting git's submodule.recurse config option to true?
这个问题 Is there a way to make git pull automatically update submodules? 有一个可接受的配置 git 的答案，如下所示：
git config --global submodule.recurse true
就像对该答案的评论之一一样，我想知道为什么这不是 git 的默认行为；更准确地说，设置此配置选项的缺点是什么？
此选项在 commit 046b482 中引入，最初用于工作树
操纵命令 (read-tree/checkout/reset)
git grep/fetch/pull/push紧随其后。
但是，如 the documentation mentions, unlike the other commands below clone still needs its own recurse flag: git clone --recurse-submodules <URL> <directory>.
看到这个 recent discussion:
This was a design decision once it was introduced, as the git clone might be too large.
Maybe we need to revisit that decision and just clone the submodules if submodule.recurse is set.
由于所涉及的子模块 number/size 可能很大，目前默认行为是默认不递归包含它们。
它们的主要缺点是由于必须在每个子模块（以及它们各自的子模块）中递归而引入的可能时间开销。
如果您有很多，并且不需要 所有 ，最好不要选择该选项，并在需要时指定 --recursive。
然而，一个优点是在切换分支时避免看到“未跟踪的文件”，as seen in this discussion。
警告，从 Git 2.34（2021 年第 4 季度）开始，git clone --recurse-submodules 意味着简单的 git pull 将递归到子模块中。
即使 git config --global submodule.recurse 未设置 。
参见“Is there a way to make git pull automatically update submodules?”。
事情是这样的：人们倾向于采用默认设置，除非他们的工作流程无法正确运行，并且 Git 的复杂性恕我直言 完全 由于工作流程它支持的品种。
您的工作流程将有很大的不同，具体取决于您是否在供应商基础上携带补丁（并且这也取决于它是在您的顶层回购还是一个或多个子模块中），您正在尝试做什么你的代码（开发新功能？测试升级？只是简单的获取和构建？），项目的设置方式（是否总是需要所有子模块来构建每个配置？将可选功能拆分成单独的历史可以带来巨大的回报），一切。
因此，调用与您正在使用的工作流程匹配或不匹配的默认值 "downside" 在我看来似乎只见树木不见森林。无论出厂默认设置如何设置，它们都可能不是您的工作流的最佳选择，至少在您的某些存储库中正是因为 Git 服务的工作流种类繁多。使默认值适合您，其他人会出现询问为什么他们默认以递归方式获取所有内容。
我唯一可以明确指出将自动递归设置为默认值的缺点是：鉴于任何人都在猜测该设置是否会匹配任何特定回购中的工作流，并且出厂默认值必须是猜猜，更糟糕的是猜出更昂贵的选项。
为您的所有工作打开自动递归配置很容易，但如果您甚至不必这样做，您可能会浪费大量时间进行克隆，而您不知道此时不需要全部。大型共享供应商历史的本地前端或参考库很容易。
When cloning or pulling a repository containing submodules the
submodules will not be checked out by default; You can instruct clone
to recurse into submodules. The init and update subcommands of git
submodule will maintain submodules checked out and at an appropriate
revision in your working tree. Alternatively you can set
submodule.recurse to have checkout recursing into submodules.
来源：git-scm.com
此选项的缺点是克隆或拉取包含多个子模块的存储库是性能成本。
我最近又回到 recurse=false 有两个原因：
- 我有我的项目需要的子模块（来自 github 的第 3 方库），但它们有我不需要的子模块。即 - 几个实例 o gtest。我不为 3rd 方库构建测试，所以获取它们是浪费时间 space
- 如果 repo 中的子模块远程更改，我会遇到问题。这通常发生在我决定库需要一些修改并且推送到上游是不可行的时候。我并没有真正调查它，因为从头开始克隆总是比弄乱子模块更容易。
recurse=false 似乎已经缓解了它，但同样：我没有完全调查这个问题。
这个问题 Is there a way to make git pull automatically update submodules? 有一个可接受的配置 git 的答案，如下所示：
git config --global submodule.recurse true
就像对该答案的评论之一一样，我想知道为什么这不是 git 的默认行为；更准确地说，设置此配置选项的缺点是什么？
此选项在 commit 046b482 中引入，最初用于工作树
操纵命令 (read-tree/checkout/reset)
git grep/fetch/pull/push紧随其后。
但是，如 the documentation mentions, unlike the other commands below clone still needs its own recurse flag: git clone --recurse-submodules <URL> <directory>.
看到这个 recent discussion:
This was a design decision once it was introduced, as the
git clonemight be too large.
Maybe we need to revisit that decision and just clone the submodules ifsubmodule.recurseis set.
由于所涉及的子模块 number/size 可能很大，目前默认行为是默认不递归包含它们。
它们的主要缺点是由于必须在每个子模块（以及它们各自的子模块）中递归而引入的可能时间开销。
如果您有很多，并且不需要 所有 ，最好不要选择该选项，并在需要时指定 --recursive。
然而，一个优点是在切换分支时避免看到“未跟踪的文件”，as seen in this discussion。
警告，从 Git 2.34（2021 年第 4 季度）开始，git clone --recurse-submodules 意味着简单的 git pull 将递归到子模块中。
即使 git config --global submodule.recurse 未设置 。
参见“Is there a way to make git pull automatically update submodules?”。
事情是这样的：人们倾向于采用默认设置，除非他们的工作流程无法正确运行，并且 Git 的复杂性恕我直言 完全 由于工作流程它支持的品种。
您的工作流程将有很大的不同，具体取决于您是否在供应商基础上携带补丁（并且这也取决于它是在您的顶层回购还是一个或多个子模块中），您正在尝试做什么你的代码（开发新功能？测试升级？只是简单的获取和构建？），项目的设置方式（是否总是需要所有子模块来构建每个配置？将可选功能拆分成单独的历史可以带来巨大的回报），一切。
因此，调用与您正在使用的工作流程匹配或不匹配的默认值 "downside" 在我看来似乎只见树木不见森林。无论出厂默认设置如何设置，它们都可能不是您的工作流的最佳选择，至少在您的某些存储库中正是因为 Git 服务的工作流种类繁多。使默认值适合您，其他人会出现询问为什么他们默认以递归方式获取所有内容。
我唯一可以明确指出将自动递归设置为默认值的缺点是：鉴于任何人都在猜测该设置是否会匹配任何特定回购中的工作流，并且出厂默认值必须是猜猜，更糟糕的是猜出更昂贵的选项。
为您的所有工作打开自动递归配置很容易，但如果您甚至不必这样做，您可能会浪费大量时间进行克隆，而您不知道此时不需要全部。大型共享供应商历史的本地前端或参考库很容易。
When cloning or pulling a repository containing submodules the submodules will not be checked out by default; You can instruct clone to recurse into submodules. The init and update subcommands of git submodule will maintain submodules checked out and at an appropriate revision in your working tree. Alternatively you can set submodule.recurse to have checkout recursing into submodules.
来源：git-scm.com
此选项的缺点是克隆或拉取包含多个子模块的存储库是性能成本。
我最近又回到 recurse=false 有两个原因：
- 我有我的项目需要的子模块（来自 github 的第 3 方库），但它们有我不需要的子模块。即 - 几个实例 o gtest。我不为 3rd 方库构建测试，所以获取它们是浪费时间 space
- 如果 repo 中的子模块远程更改，我会遇到问题。这通常发生在我决定库需要一些修改并且推送到上游是不可行的时候。我并没有真正调查它，因为从头开始克隆总是比弄乱子模块更容易。
recurse=false似乎已经缓解了它，但同样：我没有完全调查这个问题。