The documentation (git-config(1)
) says about submodule.recurse
(emphasis mine):
submodule.recurse
A boolean indicating if commands should enable the --recurse-submodules
option by default. Applies to all commands that support this option (checkout
, fetch
, grep
, pull
, push
, read-tree
, reset
, restore
and switch
) except clone
and ls-files
...
So, the submodule.recurse
option explicitly does not apply to git clone
. You need to either git clone --recurse-submodules
, or after cloning run git submodule update --init --recursive
.
Running git pull
immediately after git clone
is effectively a no-op (unless someone happens to push something immediately after the clone
operation, there won't be any changes to pull).
With submodule.recurse
set to true
, running git pull
will automatically update submodules that have a new commit in the parent repo:
$ git pull
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 2 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (2/2), 278 bytes | 278.00 KiB/s, done.
From localhost:/home/lars/tmp/demo/repo3
c07f940..044186f main -> origin/main
Fetching submodule repo1
From localhost:/home/lars/tmp/demo/repo1
cf4468f..da359ec main -> origin/main
Fetching submodule repo2
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
Updating c07f940..044186f
Fast-forward
repo1 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Successfully rebased and updated refs/heads/main.
Submodule path 'repo1': rebased into 'da359ec652e59cbd3cbc23ea405cc106519344a8'
See the Fetching submodule ...
in response to the git pull
.