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

From: Jeff King <peff@peff.net>
Date: Nov 24, 2025, 23:55 UTC
Message-ID: <20251124235530.GC2051672@coredump.intra.peff.net>
In-Reply-To: <xmqq8qfvw2lh.fsf@gitster.g>

On Mon, Nov 24, 2025 at 01:19:22PM -0800, Junio C Hamano wrote:

Show 20 quoted lines

> 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.

I was surprised that a single "-c foo" argument would work, but it makes sense: it is the "stuck" form of the short option "-c". So:

  git cmd -cfoo

should be the equivalent of:

  git cmd -c foo

whenever "-c" takes an option. It is just surprising to read because of the leading space in the value.

Using the long option as a single string, like:

  git clone '--config KEY=VALUE'

did not ever work (and should not), because there is no option of that name. It is only the stuck form:

  git clone '--config= KEY=VALUE'

which again makes sense from the config parser's perspective. It's just funny that the first character of the option value is a space.

So I don't think there are any errors in the option-parser side. It's just that we were overly lenient with trimming space in interpretation of " KEY=VALUE" itself. Which has now either been corrected, or erroneously broken, depending on your view. ;)

Show 5 quoted lines

> 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.

I don't think we're very consistent here. Look at --reference, --origin, --branch, and others. I don't know if we have an existing style recommendation here (though we do recommend the "stuck" form in gitcli, which perhaps argues that we should be using that in our documentation). So I don't know that I'd call it a bug, but it may be a good long-term project to make the presentation of options more consistent.

Show 9 quoted lines

> 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 yes, we did allow that until recently, along with:

  git clone -c ' foo.bar   = baz'

which keeps the space in the value "baz", but otherwise sets foo.bar.

I agree it was certainly surprising. Despite the real-world report that started this thread, it is oddball enough that I do not think we want to continue supporting it even for historical reasons. It is not quite at the level of https://xkcd.com/1172/, but especially the form that the OP showed looks like a mistaken invocation that happened to work (and would not work for any other option in general).

-Peff