Re: [BUG] `git clone '-c KEY=VALUE'` no longer works

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 24, 2025, 21:19 UTC
Message-ID: <xmqq8qfvw2lh.fsf@gitster.g>
In-Reply-To: <CALnO6CBJppT3ELyu54rJvP+uqcMomJS9Nr_JTgfssn8iqG7MWA@mail.gmail.com>

"D. Ben Knoble" <ben.knoble@gmail.com> writes:

Show 16 quoted lines

> On Mon, Nov 24, 2025 at 12:23 AM Ran Ari-Gur <ran.arigur+git@samsara.com> wrote:
>>
>> Hi,
>>
>> There's a small regression in Git v2.52.0; it used to be that a command of the
>> form
>>
>>     git clone '-c KEY=VALUE' ...
>>
>> or
>>
>>     git clone '--config= KEY=VALUE' ...
>>
>> would trim whitespace around KEY, making the command equivalent to this:
>>
>>     git clone --config=KEY=VALUE ...

Hmph, as documented in "git help clone",

    `-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
            linkgit:git-config[1] (e.g., `core.eol=true`).

I do not offhand know if the option really used to behave as the original report described, but if

	git clone '-c KEY=VALUE'
	git clone '--config KEY=VALUE'

does not complain-and-barf in the first place, I think that is a bug. The above option description clearly asks the user to give the dashed option (either "-c" or "--config") and "<key>=<value>" as two separate arguments on the command line.

Interestingly, unlike other long options described nearby, we do not seem to even list "--config=K=V" form, and that is a documentation bug---other options like "server-option" is described to use "=" after it before its value, and to parse the "--config K=V", the code uses the same mechanism.

Also, if the user writes

	git clone -c ' KEY=VALUE'
	git clone --config ' KEY=VALUE'

and we behaved as if it were "KEY=VALUE", that is another bug. As documented, "key" is in the format as expected by "git config", and we never allowed leading or trailing whitespaces around the key names.

So I dunno.