Re: [PATCH 2/2] config: allow specifying config entries via envvar pairs
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Nov 17, 2020, 06:28 UTC
- Message-ID
- <X7NtovvfE7IjWzie@ncase>
- In-Reply-To
- <xmqqy2j1851k.fsf@gitster.c.googlers.com>
On Mon, Nov 16, 2020 at 11:39:35AM -0800, Junio C Hamano wrote:
Show 24 quoted lines
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > > > On Fri, Nov 13 2020, Patrick Steinhardt wrote: > > > >> While not document, it is currently possible to specify config entries > > > > "While not documented..." > > > >> + strbuf_addf(&envvar, "GIT_CONFIG_KEY_%d", i); > >> + if ((key = getenv(envvar.buf)) == NULL) > >> + break; > > > > The convention in git.git is to avoid explicit NULL checks. So maybe > > something like this, which also avoids the assignment inside an "if" > > > > key = getenv(envvar.buf); > > if (!key) > > break; > > All good suggestions, but... > > "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.
Agreed
Show 6 quoted lines
> I especially do not think we want to read from unbounded number of > GIT_CONFIG_KEY_<N> variables like this patch does. How would a > script cleanse its environment to protect itself from stray such > environment variable pair? Count up from 1 to forever? Run "env" > and grep for "GIT_CONFIG_KEY_[0-9]*=" (the answer is No. What if > some environment variables have newline in its values?)
You only have to unset `GIT_CONFIG_KEY_1` as the parser will stop iterating on the first missing key. More generally, if you set `n` keys, it's sufficient to unset key `n+1`.
Patrick