From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 25 Nov 2025 01:27:01 GMT
Subject: Re: [BUG] `git clone '-c KEY=VALUE'` no longer works
Message-ID: <xmqqo6oqucka.fsf@gitster.g>
In-Reply-To: <20251124235530.GC2051672@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

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

Ahh, OK, so

	git cmd '-c foo.bar=baz'

was doing

	git cmd --config=' foo.bar=baz'

or an easier-to-read form to express in the "stuck" form of the
short option

	git cmd -c' foo.bar=baz'

which I totally missed.  I agree that the option parser is doing the
right thing for that case, including passing " foo=bar" with a
leading space as its value.

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

After you explained the "that's stuck form with leading whitespace
in the value" I missed, I wasn't so sure.  "The value is supposed to
be a configuration variable, followed by an equal sign, followed by
its value; what good does it do if we retained the leading
whitespace---stripping is a usability feature" would work as an
argument in this particular case, even though it may not work in
general.  Of course, the right thing to do when "git clone -c"
option was introduced would have been to notice that the stripping
of spaces is unwelcome complication of the UI and reject/correct it,
but it is way too late for that now.

The right right thing to do at this point may be to fix the
regression and at the same time mark the "feature" as deprecated,
and remove it following the usual deprecation procedure, but that
certainly sounds like an unnecessary waste of engineering effort.

So, I dunno.