All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.