On Mon, Oct 22 2018, SZEDER Gábor wrote:

> This allows us to run test with non-GETTEXT POISON-ed behavior even in
> a GETTEXT POISON build by running:
>
>   GIT_GETTEXT_POISON= ./t1234-foo.sh
>
> Signed-off-by: SZEDER Gábor <szeder....@gmail.com>
> ---
>  Makefile  | 2 +-
>  gettext.c | 9 +++++++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index ad880d1fc5..7a165445cd 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -365,7 +365,7 @@ all::
>  # Define GETTEXT_POISON if you are debugging the choice of strings marked
>  # for translation.  In a GETTEXT_POISON build, you can turn all strings 
> marked
>  # for translation into gibberish by setting the GIT_GETTEXT_POISON variable
> -# (to any value) in your environment.
> +# to a non-empty value in your environment.
>  #
>  # Define JSMIN to point to JavaScript minifier that functions as
>  # a filter to have gitweb.js minified.
> diff --git a/gettext.c b/gettext.c
> index 7272771c8e..a9509a5df3 100644
> --- a/gettext.c
> +++ b/gettext.c
> @@ -50,8 +50,13 @@ const char *get_preferred_languages(void)
>  int use_gettext_poison(void)
>  {
>       static int poison_requested = -1;
> -     if (poison_requested == -1)
> -             poison_requested = getenv("GIT_GETTEXT_POISON") ? 1 : 0;
> +     if (poison_requested == -1) {
> +             const char *v = getenv("GIT_GETTEXT_POISON");
> +             if (v && *v)
> +                     poison_requested = 1;
> +             else
> +                     poison_requested = 0;
> +     }
>       return poison_requested;
>  }
>  #endif

Fixing this is good. But when the initial support for conditional runs
was added in 309552295a ("i18n: do not poison translations unless
GIT_GETTEXT_POISON envvar is set", 2011-02-22) we didn't have the
convention of using git_env_bool() for these, which a few recent
follow-up patches have also done.

So let's just use git_env_bool() here. It's less code, and consistent
with the rest. See 4c2db93807 ("read-cache.c: make $GIT_TEST_SPLIT_INDEX
boolean", 2018-04-14). Also makes sense to document this in the "Running
tests with special setups" setup that patch added.

Reply via email to