Subject: Re: [PATCH 2/2] config: allow specifying config entries via envvar pairs

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Tue, 17 Nov 2020 15:22:05 +0100

On Tue, Nov 17 2020, Jeff King wrote:

> On Mon, Nov 16, 2020 at 11:39:35AM -0800, Junio C Hamano wrote:
>
>> >> While not document, it is currently possible to specify config entries
>> >> [in GIT_CONFIG_PARAMETERS]
>> [...]
>>
>> "While not documented" yes, for sure, but we do not document it for
>> a good reason---it is a pure implementation detail between Git
>> process that runs another one as its internal implementation detail.
>
> I have actually been quite tempted to document and promise that it will
> continue to work. Because it really is useful in some instances. The
> thing that has held me back is that the documentation would reveal how
> unforgiving the parser is. ;)
>
> It insists that key/value pairs are shell-quoted as a whole. I think if
> we made it accept a some reasonable inputs:
>
>   - do not require quoting for values that do not need it
>
>   - allow any amount of shell-style single-quoting (whole parameters,
>     just values, etc).
>
>   - do not bother allowing other quoting, like double-quotes with
>     backslashes. However, document backslash and double-quote as
>     meta-characters that must not appear outside of single-quotes, to
>     allow for future expansion.
>
> then I'd feel comfortable making it a public-facing feature. And for
> most cases it would be pretty pleasant to use (and for the unpleasant
> ones, I'm not sure that a little quoting is any worse than the paired
> environment variables found here).

I wonder if something like the git config -z format wouldn't be easier,
with the twist that we'd obviously not support \0. So we'd need an
optional length prefix. : = unspecified.

    :user.name
    Jeff K
    :alias.ci
    commit
    :10:bin.ary
    <10 byte string, might have a \n>
    :other.key
    Other Value

Maybe that's overly fragile, or maybe another format would be better. I
was trying to come up with one where the common case wouldn't require
knowing about shell quoting/unquoting, and where you could still do:

    GIT_CONFIG_PARAMETERS=":my.new\nvalue\n$GIT_CONFIG_PARAMETERS"

Or equivalent, and still just keep $GIT_CONFIG_PARAMETERS as-is to pass
it along.

Your "do not require quoting" accomplishes that, and it's arguably a lot