Re: [PATCH 2/2] config: allow specifying config entries via envvar pairs
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Nov 17, 2020, 14:22 UTC
- Message-ID
- <873618f4he.fsf@evledraar.gmail.com>
- In-Reply-To
- <20201117023454.GA34754@coredump.intra.peff.net>
On Tue, Nov 17 2020, Jeff King wrote:
Show 32 quoted lines
> 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 ValueMaybe 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