From: Jeff King <peff@peff.net>
Date: Mon, 24 Nov 2025 22:57:34 GMT
Subject: Re: [BUG] `git clone '-c KEY=VALUE'` no longer works
Message-ID: <20251124225734.GB2051672@coredump.intra.peff.net>
In-Reply-To: <CALnO6CBJppT3ELyu54rJvP+uqcMomJS9Nr_JTgfssn8iqG7MWA@mail.gmail.com>

On Mon, Nov 24, 2025 at 11:20:05AM -0500, D. Ben Knoble wrote:

> Thanks! As far as backward compatibility, I think this behavior has
> been around since 2010's 8b1fa77867 (Allow passing of configuration
> parameters in the command line, 2010-03-26) which morphed via
> 572e4f6a0c (Use strbufs instead of open-coded string manipulation,
> 2010-03-26) into the strbuf_trim(pair[0]) that you pointed to as
> disappearing.
> 
> Interestingly, I note that we dropped the trim around pair[1] in
> 06eb708f33 (config: always parse GIT_CONFIG_PARAMETERS during
> git_config, 2011-05-24), but I don't see that discussed in the commit
> message either. I tried a handful of mailing list searches around
> 20110524224955.GC24527@sigill.intra.peff.net, but didn't find any
> relevant discussion (though my lore-search skills are mediocre).

Yeah, there's really not much (any) discussion in that thread. I don't
recall why I would have removed the trim on the value side, but I don't
think it was an intentional choice. I don't think either trim (key or
value) really makes much sense. I'm kind of puzzled why we had them.

I thought it first it was to be lenient in the environment list.  This
code was originally for "git -c foo.bar=baz", and we are not even
parsing it directly there. It gets shoved into GIT_CONFIG_PARAMETERS and
then re-parsed from there. So I think it was an attempt to be lenient
about writing:

  GIT_CONFIG_PARAMETERS="foo.bar=baz     other.key=whatever"

But it predates that! The environment passing came in 2b64fc894d (pass
"git -c foo=bar" params through environment, 2010-08-23). And it always
shell-quotes the names, like:

  GIT_CONFIG_PARAMETERS="'foo.bar=baz' 'other.key=whatever'"

so the extra whitespace would need to be inside the shell quotes to
matter. So it seems like it really was about allowing:

  git -c ' foo.bar=baz ' ...

to work. Which seems odd. And as an added bonus, that was already
broken! In 1ff21c05ba (config: store "git -c" variables using more
robust format, 2021-01-12) we switched to a different format which does
not call git_config_parse_parameter() at all, and does not do the extra
trim. (The old code is still there to read the non-robust format, but
new Git will never write it).

So this recent refactoring of the function is left affecting only "git
clone -c", which does not pass through the environment (we write the
variables out directly into the newly-cloned repo's config).

While it is a change of behavior, I'm tempted to say that it was not
something that was ever intended to work, and not worth going back now
to restore.

-Peff