{"thread":{"id":"65100","subject":"submodule.recurse, fetch.recurseSubmodules = on-demand","startedAt":"2026-02-28T20:53:43Z","lastAt":"2026-02-28T20:53:43Z","messageCount":1,"participants":["D. Ben Knoble"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"537408","messageId":"CALnO6CBKGh=izxL2zZ-3Arsmja=Ttm1DBJf3_attLCez=57OVw@mail.gmail.com","threadId":"65100","inReplyTo":null,"subject":"submodule.recurse, fetch.recurseSubmodules = on-demand","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-02-28T20:53:31Z","receivedAt":"2026-02-28T20:53:43Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"I have just noticed that the order of these options in the config\nmatters (latest wins), even though they seem slightly separate to me.\n\nGoing just by the documentation, I would expect \"submodule.recurse =\ntrue\" coupled with \"fetch.recurseSubmodules = on-demand\" of the other\noptions to imply --recurse-submodules=on-demand; today, you can get\nthe equivalent of \"--recurse-submodules=true\" depending on how you\norder these options in your config files.\n\nThis appears to also affect push.recurseSubmodules, since the code is similar.\n\nThe code, of course, just writes the same internal config variable\nwhen it sees either option; see builtin/fetch.c:git_fetch_config and\nbuiltin/push.c:git_push_config.\n\nSo I suppose I should ask: was this intentional? I didn't see much\ndiscussion on the mailing list thread for v2, v3 of the series that\nintroduced submodule.recurse.\n\nWould we consider it a breaking change (therefore a no-no?) to adjust\noption parsing for these 2 that the more-specific values can win? Or\nshould we document somewhere (?) that the order matters?\n\n-- \nD. Ben Knoble\n"}]}