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

Ævar Arnfjörð Bjarmason  [off-list ref] 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 reason for not doing:

       test_lazy_prereq GETTEXT_POISON 'test-tool gettext-poison'
       test_lazy_prereq C_LOCALE_OUTPUT '! test-tool gettext-poison'

   In test-lib.sh is because there's some interpolation problem with
   that syntax which makes t6040-tracking-info.sh fail. Hence using
   the simpler test_set_prereq.

s/In/in/, as you haven't finished the sentence yet.  But more
importantly, what is this "some interpolation problem"?  Are you
saying that test_lazy_prereq implementation is somehow broken and
cannot take certain strings?  If so, perhaps we want to fix that,
and people other than you can help to do so, once you let them know
what the problem is.

See also
https://public-inbox.org/git/871s8gd32p.fsf@evledraar.gmail.com/ for
more discussion.

"See also [*1*] for more discussion" as you've already have
reference below.

1. https://public-inbox.org/git/871s8gd32p.fsf@evledraar.gmail.com/

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---

Here's a polished version of that. I think it makes sense to queue
this up before any other refactoring of GETTEXT_POISON, and some patch
to unconditionally preserve format specifiers as I suggested upthread
could go on top of this.
...
+int cmd_sh_i18n__helper(int argc, const char **argv, const char *prefix)
+{
+	int poison = -1;
+	struct option options[] = {
+		OPT_BOOL(0, "git-test-gettext-poison", &poison,
+			 N_("is GIT_TEST_GETTEXT_POISON in effect?")),
+		OPT_END()
+	};
+
+	argc = parse_options(argc, argv, NULL, options,
+			     builtin_sh_i18n_helper_usage, PARSE_OPT_KEEP_ARGV0);
+
+	if (poison != -1)
+		return !git_env_bool("GIT_TEST_GETTEXT_POISON", 0);

Hmm?  If "--[no-]git-test-gettext-poison" is given, poison is either
0 or 1, and we return the value we read from the environment?  What
convoluted way to implement the option is that, or is there anything
subtle that I am not getting?

If the "default" parameter to git_env_bool() were poison, and then
the option was renamed to "--get-git-text-gettext-poison", then I
sort of understand the code, though (it's like "git config" with
"--default" option).

But if there is nothing subtle, it may make sense to implement this
as an opt-cmdmode instead.

s/these Git tested/these, Git can be tested/; even though the comma
is not a new issue you introduced.