"Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: > On Fri, Oct 07, 2022 at 01:09:39PM +0200, Ævar Arnfjörð Bjarmason wrote: >> >> On Fri, Oct 07 2022, Michael S. Tsirkin wrote: >> >> > THE CONFIGURATION OF SUBMODULES >> > Submodule operations can be configured using the following mechanisms (from highest to lowest precedence): >> > >> > • The command line for those commands that support taking submodules as part of their pathspecs. Most commands have a boolean >> > flag --recurse-submodules which specify whether to recurse into submodules. Examples are grep and checkout. Some commands >> > take enums, such as fetch and push, where you can specify how submodules are affected. >> > >> > • The configuration inside the submodule. This includes $GIT_DIR/config in the submodule, but also settings in the tree such >> > as a .gitattributes or .gitignore files that specify behavior of commands inside the submodule. >> > >> > For example an effect from the submodule’s .gitignore file would be observed when you run git status >> > --ignore-submodules=none in the superproject. This collects information from the submodule’s working directory by running >> > status in the submodule while paying attention to the .gitignore file of the submodule. >> > >> > The submodule’s $GIT_DIR/config file would come into play when running git push --recurse-submodules=check in the >> > superproject, as this would check if the submodule has any changes not published to any remote. The remotes are configured >> > in the submodule as usual in the $GIT_DIR/config file. >> > >> > • The configuration file $GIT_DIR/config in the superproject. Git only recurses into active submodules (see "ACTIVE >> > SUBMODULES" section below). >> > >> > If the submodule is not yet initialized, then the configuration inside the submodule does not exist yet, so where to obtain >> > the submodule from is configured here for example. >> > >> > • The .gitmodules file inside the superproject. A project usually uses this file to suggest defaults for the upstream >> > collection of repositories for the mapping that is required between a submodule’s name and its path. >> > >> > This file mainly serves as the mapping between the name and path of submodules in the superproject, such that the >> > submodule’s Git directory can be located. >> > >> > If the submodule has never been initialized, this is the only place where submodule configuration is found. It serves as >> > the last fallback to specify where to obtain the submodule from. >> > >> > >> > However, when we are talking about the recurse attribute, it is >> > not taken from .gitmodules - only command line and .git/config seem >> > to be consulted. >> > Is this a bug or a feature? >> >> It's a (security) feature. We have had disussions[1] about how to safely >> read in-repo config, but we are very far away from that becoming a >> reality (if it ever happens). >> >> If we read this from the .gitmodules the repo could change how you >> interact with your submodules. >> >> 1. https://lore.kernel.org/git/YzXwZQbM69eNJfm7@nand.local/ > > Hmm. Well we have a bunch of attributes there. Why this one? What did I miss? I couldn't find the `submodule.<name>.recurse` you referenced in your email subject, so I'll assume we're talking about `submodule.recurse` here. A simple reason would be that `submodule.recurse` is not specific to a single submodule so it does not come from .gitmodules. .gitmodules is a way of providing metadata for that submodules need to work correctly, e.g.: - where to get the submodule from during a fetch/clone, e.g. `submodule.<name>.url`, `submodule.<name>.branch` - information needed for submodules to work correctly, e.g. `submodule.<name>.path` - default config that gets populated in .git/config via `git submodule init`, e.g. `submodule.<name>.update`, `submodule.<name>.fetchRecurseSubmodules` With respect to config, the general stance is that .gitmodules is meant to provide defaults for .git/config and _not_ to be read directly (see Ævar's answer). There are some very limited cases where config is read directly from .gitmodules, but that approach is very frowned upon and it's unlikely that we'll add more of them in the future. > > -- > MST
