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 invoved 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 leaving 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.
Warning, starting Git 2.34 (Q4 2021), a git clone --recurse-submodules, means a simple git pull will recurse into submodules, if the config submodule.stickyRecursiveClone is set to true.
Even when git config --global submodule.recurse is not set.
See "Is there a way to make git pull automatically update submodules?".