On Wed, Oct 24, 2018 at 02:45:49PM +0900, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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
