# Bug: git config order affects outcome for recurseSubmodules settings

1 messages from 2024-11-27 to 2024-11-27. Participants: Henrik Ahlm.
Thread: https://gitlist.dev/t/62552

## Henrik Ahlm, 2024-11-27 14:17

Subject: Bug: git config order affects outcome for recurseSubmodules settings
Message-ID: <CABJpytygYtdAT7z1V44h12sLzzo5Ozf3Vc-=fE7XBQnP1G6HSg@mail.gmail.com>
URL: https://gitlist.dev/e/CABJpytygYtdAT7z1V44h12sLzzo5Ozf3Vc-%3DfE7XBQnP1G6HSg%40mail.gmail.com

```
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

```