This question Is there a way to make git pull automatically update submodules? has an accepted answer of configuring git like so:
git config --global submodule.recurse true
Like one of the comments to that answer, I'm wondering why this isn't the default behavior of git; more precisely, what are the drawbacks of setting this configuration option?
This option was introduced in commit 046b482, initially for working tree
manipulating commands (read-tree/checkout/reset)
git grep/fetch/pull/push soon followed.
However, as the documentation mentions, unlike the other commands below, clone still needs its own recurse flag: git clone --recurse-submodules <URL> <directory>.
See this 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.
As the number/size of the submodules involved can be potentially large, the default behavior is, for now, to not include them recursively by default.
The main drawback is the possible time overhead introduced by having to go recursively in each submodule (and their own respective submodules).
If you have many of them, and don't need all of them, it is best to leave that option off, and specifying --recursive when you need it.
Yet, one advantage is to avoid seeing "Untracked files" when switching branches, as seen in this discussion.
Note: Starting Git 2.34 (Q4 2021), if you have cloned a project using
git clone --recurse-submodules and have the config
submodule.stickyRecursiveClone set to true, then running
git pull will also recurse into submodules — even if
git config --global submodule.recurse is not set.
This does not happen by default; it only applies when you have chosen to enable submodule.stickyRecursiveClone.
If you are not using that config, then a git pull on a repo cloned with --recurse-submodules will not recurse into submodules unless submodule.recurse is set.
See "Is there a way to make git pull automatically update submodules?".