Bug: git config order affects outcome for recurseSubmodules settings

Bug: git config order affects outcome for recurseSubmodules settings

[Henrik Ahlm]

What did you do before the bug happened? (Steps to reproduce your issue)
Setting configs in this order will result in fetch on-demand and push
check not being respected:
git config --global fetch.recurseSubmodules on-demand
git config --global push.recurseSubmodules check
git config --global submodule.recurse true

It can be seen if you have a repo with at least one submodule. Just
call pull on a repo with no updated submodule(s) commits, and it will
still fetch from the submodule(s). Similar approach to push with
check.


What did you expect to happen? (Expected behavior)
I expected the explicit fetch/push settings to be respected, instead
of having them receive the default value from submodule.recurse.

If submodule.recurse is set before the fetch/push settings, it works
as expected.


What happened instead? (Actual behavior)
The default values were used instead of the configured setting for fetch/push.


Anything else you want to add:
The order of these settings shouldn't matter, and if
push/fetch.recurseSubmodules have received a setting, it should not
pick up a "stale" default value.

This has been tested on Ubuntu 24.04 using:
Git version 2.43.0
Git build from source from the next branch


Thank you
Henrik