Re: [bug] git clone: -c key=value missed when cloning submodules with --recurse-submodules

From: D. Ben Knoble <ben.knoble+github@gmail.com>
Date: Aug 11, 2025, 21:14 UTC
Message-ID: <CALnO6CAJsXJXDtw_ewXnV4rydmnfh4Fm=eDE9WQ0_t8BpFEi_w@mail.gmail.com>
In-Reply-To: <CAKkAvayK9WRBLtPL7XCsBP=UGbYMnDYE6+EPRpCxJioryNeBBA@mail.gmail.com>

On Mon, Aug 11, 2025 at 10:52 AM ryenus <ryenus@gmail.com> wrote:

Show 21 quoted lines

>
> Given 2 repositories, the 1st is "parent", with the 2nd as a submodule:
>
> * https://remote.host/parent
> * https://remote.host/submodule
>
> When cloning the parent repo with the below command:
>
>     git clone -c key=value --recurse-submodules https://remote.host/parent
>
> While "-c key=value" is properly applied when cloning the parent, it's
> missed when cloning the submodule.
>
> Here the actual key/value is something like "url.new.insteadOf=old" for
> authentication purpose.
>
> Fortunately the following works:
>
>     git -c key=value clone --recurse-submodules https://remote.host/parent
>
> Ideally the first form should also work.

I don't /think/ this is a bug: the manual for git(1) describes the form

    git -c <name>=<value> <command> [<args>]

as

       -c <name>=<value>
           Pass a configuration parameter to the command. The value given will
           override values from configuration files. The <name> is expected in
           the same format as listed by git config (subkeys separated by dots).

Meanwhile, the manual for git-clone(1) omits "-c" from the synopsis (?), but does say

       -c <key>=<value>, --config <key>=<value>
           Set a configuration variable in the newly-created repository; this
           takes effect immediately after the repository is initialized, but
           before the remote history is fetched or any files checked out. The
           <key> is in the same format as expected by git-config(1) (e.g.,
           core.eol=true). If multiple values are given for the same key, each
           value will be written to the config file. This makes it safe, for
           example, to add additional fetch refspecs to the origin remote.

    [ some caveats omitted ]

So they are 2 different commands, and the position of "-c" matters.

All that said… upon a re-read, I see "this [config] takes effect […] before the remote history is fetched." So let's take a look at the omitted caveats:

           Due to limitations of the current implementation, some configuration
           variables do not take effect until after the initial fetch and
           checkout. Configuration variables known to not take effect are:
           remote.<name>.mirror and remote.<name>.tagOpt. Use the corresponding
           --mirror and --no-tags options instead.

Perhaps url.<name>.insteadOf deserves mention here?