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

From: Jeff King <peff@peff.net>
Date: Nov 26, 2025, 14:53 UTC
Message-ID: <20251126145320.GA4143292@coredump.intra.peff.net>
In-Reply-To: <xmqqo6oqucka.fsf@gitster.g>

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

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

I agree that is the most conservative choice, but I'd also be comfortable just calling this a bug that was fixed. The leading space was accepted only by "git clone -c" and not "git -c". And of course there is almost no other option in all of Git where doing "-o foo" as a single argument would do the right thing[1].

I would be more sympathetic if the original report was "it is useful for so-and-so reason to do this whitespace stripping". But it really sounds like the problem was some caller doing something like (in perl pseudo-code):

  system("git", "clone", "-c $key", $repo);

instead of:

  system("git", "clone", "-c", $key, $repo);

which is just a bug that happened to work in this limited instance.

So my inclination would be to leave it be, because I do not think it merits the time. But if somebody else wants to go for it, I will not stop them. ;)

-Peff

[1] Given our recent discussion of strtol(), I actually wonder if "-x
    10" works for "-x" that takes a numeric option (because strtol would
    suck up the leading whitespace). So maybe this kind of error is
    silently lurking in more places.