Re: sudmodule.<name>.recurse ignored

["Michael S. Tsirkin" <mst@redhat.com>]

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?

-- 
MST