On Mon, Aug 11, 2025 at 10:52 AM ryenus <ryenus@xxxxxxxxx> wrote: > > 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?
