Bug: git config order affects outcome for recurseSubmodules settings

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