Re: [PATCH] i18n: make GETTEXT_POISON a runtime option

From: Jeff King <peff@peff.net>
Date: Oct 24, 2018, 07:44 UTC
Message-ID: <20181024074400.GA31239@sigill.intra.peff.net>
In-Reply-To: <xmqqefcfoq2a.fsf@gitster-ct.c.googlers.com>

On Wed, Oct 24, 2018 at 02:45:49PM +0900, Junio C Hamano wrote:

Show 20 quoted lines

> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
> 
> > Notes on the implementation:
> >
> >  * The only reason we need a new "git-sh-i18n--helper" and the
> >    corresponding "test-tool gettext-poison" is to expose
> >    git_env_bool() to shellscripts, since git-sh-i18n and friends need
> >    to inspect the $GIT_TEST_GETTEXT_POISON variable.
> >
> >    We only call these if $GIT_TEST_GETTEXT_POISON is set, or in the
> >    test suite, and this code can go away for non-test code once the
> >    last i18n-using shellscript is rewritten in C.
> 
> Makes me wonder if we want to teach "git config" a new "--env-bool"
> option that can be used by third-party scripts.  Or would it be just
> the matter of writing
> 
> 	git config --default=false --type=bool "$GIT_WHATEVER_ENV"
> 
> in these third-party scripts and we do not need to add such a thing?

The config command only takes names, not values. So you'd have to write something like:

  git -c env.bool="$GIT_WHATEVER_ENV" config --type=bool env.bool

but then you lose the default handling. I think if we added a new option, it would either be:

  # interpret a value directly; use default on empty, I guess?
  git config --default=false --type=bool --interpret-value "$GIT_WHATEVER_ENV"

or

  # less flexible, but the --default semantics are more obvious
  git config --default=false --type=bool --get-env GIT_WHATEVER_ENV

-Peff