git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: git@vger.kernel.org
Subject: Re: sudmodule.<name>.recurse ignored
Date: Fri, 07 Oct 2022 13:09:39 +0200	[thread overview]
Message-ID: <221007.86wn9bq458.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <20221007060713-mutt-send-email-mst@kernel.org>


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/

  reply	other threads:[~2022-10-07 11:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-07 10:10 sudmodule.<name>.recurse ignored Michael S. Tsirkin
2022-10-07 11:09 ` Ævar Arnfjörð Bjarmason [this message]
2022-10-07 12:56   ` Michael S. Tsirkin
2022-10-07 21:04     ` Glen Choo
2022-10-07 21:13       ` Junio C Hamano
2022-10-11 22:34         ` Michael S. Tsirkin
2022-10-12 16:56           ` Glen Choo
2022-10-12 21:49             ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=221007.86wn9bq458.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=mst@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).