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

From: Jeff King <peff@peff.net>
Date: Nov 30, 2025, 13:49 UTC
Message-ID: <20251130134930.GB199421@coredump.intra.peff.net>
In-Reply-To: <xmqqtsygoh96.fsf@gitster.g>

On Wed, Nov 26, 2025 at 09:06:45AM -0800, Junio C Hamano wrote:

Show 12 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > That doesn't trigger via "git -c", because we use the "new" form these
> > days (so it started rejecting the extra whitespace in 2021). And you'd
> > only see it if you hand-crafted the variable, or an old version of Git
> > set parameters that were then parsed by a newer one.
> >
> > So whether that is a case we care about is up for debate. But if we are
> > going to accommodate backwards compatibility, we have to decide where to
> > draw the line.
> 
> I was hoping we already drew the line above the "clone" thing ;-)

OK. :) I am OK with that, but I wanted to make sure we were doing it consciously.

Show 12 quoted lines

> > And I think the latter would still fail with your patch. Again, that
> > might not matter to us, if all we care about is making:
> >
> >   git clone '-c foo.bar=baz' ...
> >
> > work as before. But I'm still skeptical that is worthwhile (especially
> > given that nobody noticed the same change to "git -c" a few years ago).
> 
> True.
> 
> I do not think I can convince myself to care about this deeply
> enough.

That's about where I'm at, though I'm a little worried by Dscho's mention that apparently git-lfs has the same problem. So maybe it's more widespread than I am giving it credit for?

If we draw the line at "-c foo=bar" as a single argument (which is what it sounds like git-lfs is doing, too) then your simple "trim" patch would be enough.

I dunno. I certainly do not want to get into a deprecation period and all of that mess. Maybe the breakage in v2.52.0 would be enough for callers to notice and fix their invocations, and we could just quietly remove the hack later? But then, I am not sure what makes "later" any better than "now".

-Peff