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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 25, 2025, 01:27 UTC
Message-ID: <xmqqo6oqucka.fsf@gitster.g>
In-Reply-To: <20251124235530.GC2051672@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 11 quoted lines

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

Show 12 quoted lines

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