Message ID | 20181023210154.32507-1-avarab@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | i18n: make GETTEXT_POISON a runtime option | expand |
Æ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 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 <avarab@gmail.com> > --- > > 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. > diff --git a/po/README b/po/README > index fef4c0f0b5..dba46c4a40 100644 > --- a/po/README > +++ b/po/README > @@ -289,16 +289,11 @@ something in the test suite might still depend on the US English > version of the strings, e.g. to grep some error message or other > output. > > -To smoke out issues like these Git can be compiled with gettext poison > -support, at the top-level: > +To smoke out issues like these Git tested with a translation mode that > +emits gibberish on every call to gettext. To use it run the test suite > +with it, e.g.: s/these Git tested/these, Git can be tested/; even though the comma is not a new issue you introduced.
On Wed, Oct 24, 2018 at 02:45:49PM +0900, Junio C Hamano wrote: > Æ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
Jeff King <peff@peff.net> writes: > 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 Yeah, my thinko. The latter would be closer to what this patch wants to have, but obviously the former would be more flexible and useful in wider context. Both have the "Huh?" factor---what they are doing has little to do with "config", but I did not think of a better kitchen-sink (and our default kitchen-sink "rev-parse" is even further than "config", I would think, for this one).
On Thu, Oct 25, 2018 at 10:00:31AM +0900, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > > > 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 > > Yeah, my thinko. The latter would be closer to what this patch > wants to have, but obviously the former would be more flexible and > useful in wider context. Both have the "Huh?" factor---what they > are doing has little to do with "config", but I did not think of a > better kitchen-sink (and our default kitchen-sink "rev-parse" is > even further than "config", I would think, for this one). Heh, I thought through the exact sequence in your paragraph when writing my other message. That's probably a good sign that we should probably not pursue this further unless we see the use case come up again a few more times (and if we do, then consider "config" the least-bad place to do it). -Peff
On 25/10/2018 02:09, Jeff King wrote: > On Thu, Oct 25, 2018 at 10:00:31AM +0900, Junio C Hamano wrote: > >> Jeff King <peff@peff.net> writes: >> >>> 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 >> >> Yeah, my thinko. The latter would be closer to what this patch >> wants to have, but obviously the former would be more flexible and >> useful in wider context. Both have the "Huh?" factor---what they >> are doing has little to do with "config", but I did not think of a >> better kitchen-sink (and our default kitchen-sink "rev-parse" is >> even further than "config", I would think, for this one). > > Heh, I thought through the exact sequence in your paragraph when writing > my other message. That's probably a good sign that we should probably > not pursue this further unless we see the use case come up again a few > more times (and if we do, then consider "config" the least-bad place to > do it). I was thinking: $ git var -e GIT_WHATEVER_ENV [-e for environment]. ... but that is really no different than git-config. ;-) ATB, Ramsay Jones
On Thu, Oct 25, 2018 at 02:24:41AM +0100, Ramsay Jones wrote: > >> Yeah, my thinko. The latter would be closer to what this patch > >> wants to have, but obviously the former would be more flexible and > >> useful in wider context. Both have the "Huh?" factor---what they > >> are doing has little to do with "config", but I did not think of a > >> better kitchen-sink (and our default kitchen-sink "rev-parse" is > >> even further than "config", I would think, for this one). > > > > Heh, I thought through the exact sequence in your paragraph when writing > > my other message. That's probably a good sign that we should probably > > not pursue this further unless we see the use case come up again a few > > more times (and if we do, then consider "config" the least-bad place to > > do it). > > I was thinking: > > $ git var -e GIT_WHATEVER_ENV > > [-e for environment]. > > ... but that is really no different than git-config. ;-) Actually, "git var" already does pull bits from the environment. It doesn't know about all of the type-specific parsing that git-config does, but it might be a reasonable path forward to teach it that. (But I still think we should do nothing for now and see how often this comes up). -Peff
On Thu, Oct 25 2018, Jeff King wrote: > On Thu, Oct 25, 2018 at 02:24:41AM +0100, Ramsay Jones wrote: > >> >> Yeah, my thinko. The latter would be closer to what this patch >> >> wants to have, but obviously the former would be more flexible and >> >> useful in wider context. Both have the "Huh?" factor---what they >> >> are doing has little to do with "config", but I did not think of a >> >> better kitchen-sink (and our default kitchen-sink "rev-parse" is >> >> even further than "config", I would think, for this one). >> > >> > Heh, I thought through the exact sequence in your paragraph when writing >> > my other message. That's probably a good sign that we should probably >> > not pursue this further unless we see the use case come up again a few >> > more times (and if we do, then consider "config" the least-bad place to >> > do it). >> >> I was thinking: >> >> $ git var -e GIT_WHATEVER_ENV >> >> [-e for environment]. >> >> ... but that is really no different than git-config. ;-) > > Actually, "git var" already does pull bits from the environment. It > doesn't know about all of the type-specific parsing that git-config > does, but it might be a reasonable path forward to teach it that. (But I > still think we should do nothing for now and see how often this comes > up). For myself / Junio picking this up: Does that mean you've read v2 and think it's OK to pick up in its current form? I think it is, just looking for some Acks on that since it's not in the latest "What's Cooking".
On Fri, Oct 26, 2018 at 09:20:56PM +0200, Ævar Arnfjörð Bjarmason wrote: > >> I was thinking: > >> > >> $ git var -e GIT_WHATEVER_ENV > >> > >> [-e for environment]. > >> > >> ... but that is really no different than git-config. ;-) > > > > Actually, "git var" already does pull bits from the environment. It > > doesn't know about all of the type-specific parsing that git-config > > does, but it might be a reasonable path forward to teach it that. (But I > > still think we should do nothing for now and see how often this comes > > up). > > For myself / Junio picking this up: Does that mean you've read v2 and > think it's OK to pick up in its current form? I think it is, just > looking for some Acks on that since it's not in the latest "What's > Cooking". I'm not sure if you're asking whether I looked at the rest of the patch. If so, then no, not really (so no objection, but I also did not review it). -Peff
On Sat, Oct 27 2018, Jeff King wrote: > On Fri, Oct 26, 2018 at 09:20:56PM +0200, Ævar Arnfjörð Bjarmason wrote: > >> >> I was thinking: >> >> >> >> $ git var -e GIT_WHATEVER_ENV >> >> >> >> [-e for environment]. >> >> >> >> ... but that is really no different than git-config. ;-) >> > >> > Actually, "git var" already does pull bits from the environment. It >> > doesn't know about all of the type-specific parsing that git-config >> > does, but it might be a reasonable path forward to teach it that. (But I >> > still think we should do nothing for now and see how often this comes >> > up). >> >> For myself / Junio picking this up: Does that mean you've read v2 and >> think it's OK to pick up in its current form? I think it is, just >> looking for some Acks on that since it's not in the latest "What's >> Cooking". > > I'm not sure if you're asking whether I looked at the rest of the patch. > If so, then no, not really (so no objection, but I also did not review > it). Yeah I'm fishing for a more general review than just the problem of how we turn an env variable into a boolean, so if you or anyone else is up for it it would be most welcome :)
diff --git a/.gitignore b/.gitignore index 9d1363a1eb..f7b7977910 100644 --- a/.gitignore +++ b/.gitignore @@ -148,6 +148,7 @@ /git-serve /git-sh-i18n /git-sh-i18n--envsubst +/git-sh-i18n--helper /git-sh-setup /git-sh-i18n /git-shell diff --git a/.travis.yml b/.travis.yml index 4d4e26c9df..4523a2e5ec 100644 --- a/.travis.yml +++ b/.travis.yml @@ -26,7 +26,7 @@ addons: matrix: include: - - env: jobname=GETTEXT_POISON + - env: jobname=GIT_TEST_GETTEXT_POISON os: linux compiler: addons: diff --git a/Makefile b/Makefile index d18ab0fe78..684dec4d39 100644 --- a/Makefile +++ b/Makefile @@ -362,11 +362,6 @@ all:: # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the # user. # -# 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. -# # Define JSMIN to point to JavaScript minifier that functions as # a filter to have gitweb.js minified. # @@ -714,6 +709,7 @@ TEST_BUILTINS_OBJS += test-dump-split-index.o TEST_BUILTINS_OBJS += test-dump-untracked-cache.o TEST_BUILTINS_OBJS += test-example-decorate.o TEST_BUILTINS_OBJS += test-genrandom.o +TEST_BUILTINS_OBJS += test-gettext-poison.o TEST_BUILTINS_OBJS += test-hashmap.o TEST_BUILTINS_OBJS += test-index-version.o TEST_BUILTINS_OBJS += test-json-writer.o @@ -1099,6 +1095,7 @@ BUILTIN_OBJS += builtin/revert.o BUILTIN_OBJS += builtin/rm.o BUILTIN_OBJS += builtin/send-pack.o BUILTIN_OBJS += builtin/serve.o +BUILTIN_OBJS += builtin/sh-i18n--helper.o BUILTIN_OBJS += builtin/shortlog.o BUILTIN_OBJS += builtin/show-branch.o BUILTIN_OBJS += builtin/show-index.o @@ -1439,9 +1436,6 @@ endif ifdef NO_SYMLINK_HEAD BASIC_CFLAGS += -DNO_SYMLINK_HEAD endif -ifdef GETTEXT_POISON - BASIC_CFLAGS += -DGETTEXT_POISON -endif ifdef NO_GETTEXT BASIC_CFLAGS += -DNO_GETTEXT USE_GETTEXT_SCHEME ?= fallthrough @@ -2591,7 +2585,6 @@ ifdef GIT_TEST_CMP_USE_COPIED_CONTEXT @echo GIT_TEST_CMP_USE_COPIED_CONTEXT=YesPlease >>$@+ endif @echo NO_GETTEXT=\''$(subst ','\'',$(subst ','\'',$(NO_GETTEXT)))'\' >>$@+ - @echo GETTEXT_POISON=\''$(subst ','\'',$(subst ','\'',$(GETTEXT_POISON)))'\' >>$@+ ifdef GIT_PERF_REPEAT_COUNT @echo GIT_PERF_REPEAT_COUNT=\''$(subst ','\'',$(subst ','\'',$(GIT_PERF_REPEAT_COUNT)))'\' >>$@+ endif diff --git a/builtin.h b/builtin.h index 962f0489ab..a40c56e7a2 100644 --- a/builtin.h +++ b/builtin.h @@ -219,6 +219,7 @@ extern int cmd_revert(int argc, const char **argv, const char *prefix); extern int cmd_rm(int argc, const char **argv, const char *prefix); extern int cmd_send_pack(int argc, const char **argv, const char *prefix); extern int cmd_serve(int argc, const char **argv, const char *prefix); +extern int cmd_sh_i18n__helper(int argc, const char **argv, const char *prefix); extern int cmd_shortlog(int argc, const char **argv, const char *prefix); extern int cmd_show(int argc, const char **argv, const char *prefix); extern int cmd_show_branch(int argc, const char **argv, const char *prefix); diff --git a/builtin/sh-i18n--helper.c b/builtin/sh-i18n--helper.c new file mode 100644 index 0000000000..1fba8b902b --- /dev/null +++ b/builtin/sh-i18n--helper.c @@ -0,0 +1,27 @@ +#include "builtin.h" +#include "cache.h" +#include "config.h" +#include "parse-options.h" + +static const char * const builtin_sh_i18n_helper_usage[] = { + N_("git sh-i18n--helper [<options>]"), + NULL +}; + +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); + + usage_with_options(builtin_sh_i18n_helper_usage, options); +} diff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh index 06970f7213..6a89d0d7d8 100755 --- a/ci/lib-travisci.sh +++ b/ci/lib-travisci.sh @@ -123,7 +123,7 @@ osx-clang|osx-gcc) # Travis CI OS X export GIT_SKIP_TESTS="t9810 t9816" ;; -GETTEXT_POISON) - export GETTEXT_POISON=YesPlease +GIT_TEST_GETTEXT_POISON) + export GIT_TEST_GETTEXT_POISON=true ;; esac diff --git a/gettext.c b/gettext.c index 7272771c8e..722a2f726c 100644 --- a/gettext.c +++ b/gettext.c @@ -7,6 +7,7 @@ #include "gettext.h" #include "strbuf.h" #include "utf8.h" +#include "config.h" #ifndef NO_GETTEXT # include <locale.h> @@ -46,15 +47,13 @@ const char *get_preferred_languages(void) return NULL; } -#ifdef GETTEXT_POISON int use_gettext_poison(void) { static int poison_requested = -1; if (poison_requested == -1) - poison_requested = getenv("GIT_GETTEXT_POISON") ? 1 : 0; + poison_requested = git_env_bool("GIT_TEST_GETTEXT_POISON", 0); return poison_requested; } -#endif #ifndef NO_GETTEXT static int test_vsnprintf(const char *fmt, ...) diff --git a/gettext.h b/gettext.h index 7eee64a34f..4c492d9f57 100644 --- a/gettext.h +++ b/gettext.h @@ -41,11 +41,7 @@ static inline int gettext_width(const char *s) } #endif -#ifdef GETTEXT_POISON extern int use_gettext_poison(void); -#else -#define use_gettext_poison() 0 -#endif static inline FORMAT_PRESERVING(1) const char *_(const char *msgid) { diff --git a/git-sh-i18n.sh b/git-sh-i18n.sh index 9d065fb4bf..c0713b1ee9 100644 --- a/git-sh-i18n.sh +++ b/git-sh-i18n.sh @@ -17,7 +17,8 @@ export TEXTDOMAINDIR # First decide what scheme to use... GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough -if test -n "$GIT_GETTEXT_POISON" +if test -n "$GIT_TEST_GETTEXT_POISON" && + git sh-i18n--helper --git-test-gettext-poison then GIT_INTERNAL_GETTEXT_SH_SCHEME=poison elif test -n "@@USE_GETTEXT_SCHEME@@" diff --git a/git.c b/git.c index 5920f8019b..125c523720 100644 --- a/git.c +++ b/git.c @@ -539,6 +539,7 @@ static struct cmd_struct commands[] = { { "rm", cmd_rm, RUN_SETUP }, { "send-pack", cmd_send_pack, RUN_SETUP }, { "serve", cmd_serve, RUN_SETUP }, + { "sh-i18n--helper", cmd_sh_i18n__helper, 0 }, { "shortlog", cmd_shortlog, RUN_SETUP_GENTLY | USE_PAGER }, { "show", cmd_show, RUN_SETUP }, { "show-branch", cmd_show_branch, RUN_SETUP }, diff --git a/po/README b/po/README index fef4c0f0b5..dba46c4a40 100644 --- a/po/README +++ b/po/README @@ -289,16 +289,11 @@ something in the test suite might still depend on the US English version of the strings, e.g. to grep some error message or other output. -To smoke out issues like these Git can be compiled with gettext poison -support, at the top-level: +To smoke out issues like these Git tested with a translation mode that +emits gibberish on every call to gettext. To use it run the test suite +with it, e.g.: - make GETTEXT_POISON=YesPlease - -That'll give you a git which emits gibberish on every call to -gettext. It's obviously not meant to be installed, but you should run -the test suite with it: - - cd t && prove -j 9 ./t[0-9]*.sh + cd t && GIT_TEST_GETTEXT_POISON=true prove -j 9 ./t[0-9]*.sh If tests break with it you should inspect them manually and see if what you're translating is sane, i.e. that you're not translating diff --git a/t/README b/t/README index 8847489640..53c3dee7a9 100644 --- a/t/README +++ b/t/README @@ -301,6 +301,12 @@ that cannot be easily covered by a few specific test cases. These could be enabled by running the test suite with correct GIT_TEST_ environment set. +GIT_TEST_GETTEXT_POISON=<boolean> turns all strings marked for +translation into gibberish. Used for spotting those tests that need to +be marked with a C_LOCALE_OUTPUT prerequisite when adding more strings +for translation. See "Testing marked strings" in po/README for +details. + GIT_TEST_SPLIT_INDEX=<boolean> forces split-index mode on the whole test suite. Accept any boolean values that are accepted by git-config. diff --git a/t/helper/test-gettext-poison.c b/t/helper/test-gettext-poison.c new file mode 100644 index 0000000000..476be95da5 --- /dev/null +++ b/t/helper/test-gettext-poison.c @@ -0,0 +1,9 @@ +#include "test-tool.h" +#include "git-compat-util.h" +#include "thread-utils.h" +#include "gettext.h" + +int cmd__gettext_poison(int argc, const char **argv) +{ + return use_gettext_poison() ? 0 : 1; +} diff --git a/t/helper/test-tool.c b/t/helper/test-tool.c index 6b5836dc1b..3e75672a37 100644 --- a/t/helper/test-tool.c +++ b/t/helper/test-tool.c @@ -19,6 +19,7 @@ static struct test_cmd cmds[] = { { "dump-untracked-cache", cmd__dump_untracked_cache }, { "example-decorate", cmd__example_decorate }, { "genrandom", cmd__genrandom }, + { "gettext-poison", cmd__gettext_poison }, { "hashmap", cmd__hashmap }, { "index-version", cmd__index_version }, { "json-writer", cmd__json_writer }, diff --git a/t/helper/test-tool.h b/t/helper/test-tool.h index e4890566da..04f033b7fc 100644 --- a/t/helper/test-tool.h +++ b/t/helper/test-tool.h @@ -15,6 +15,7 @@ int cmd__dump_split_index(int argc, const char **argv); int cmd__dump_untracked_cache(int argc, const char **argv); int cmd__example_decorate(int argc, const char **argv); int cmd__genrandom(int argc, const char **argv); +int cmd__gettext_poison(int argc, const char **argv); int cmd__hashmap(int argc, const char **argv); int cmd__index_version(int argc, const char **argv); int cmd__json_writer(int argc, const char **argv); diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh index 4d23373526..b6566003dd 100755 --- a/t/t0000-basic.sh +++ b/t/t0000-basic.sh @@ -274,7 +274,7 @@ test_expect_success 'pretend we have a mix of all possible results' " EOF " -test_expect_success 'test --verbose' ' +test_expect_success C_LOCALE_OUTPUT 'test --verbose' ' test_must_fail run_sub_test_lib_test \ test-verbose "test verbose" --verbose <<-\EOF && test_expect_success "passing test" true diff --git a/t/t3406-rebase-message.sh b/t/t3406-rebase-message.sh index 0392e36d23..2bdcf83808 100755 --- a/t/t3406-rebase-message.sh +++ b/t/t3406-rebase-message.sh @@ -77,7 +77,7 @@ test_expect_success 'rebase -n overrides config rebase.stat config' ' # "Does not point to a valid commit: invalid-ref" # # NEEDSWORK: This "grep" is fine in real non-C locales, but -# GETTEXT_POISON poisons the refname along with the enclosing +# GIT_TEST_GETTEXT_POISON poisons the refname along with the enclosing # error message. test_expect_success 'rebase --onto outputs the invalid ref' ' test_must_fail git rebase --onto invalid-ref HEAD HEAD 2>err && diff --git a/t/t7201-co.sh b/t/t7201-co.sh index 826987ca80..cb2c8cf3f3 100755 --- a/t/t7201-co.sh +++ b/t/t7201-co.sh @@ -256,7 +256,10 @@ test_expect_success 'checkout to detach HEAD' ' git checkout -f renamer && git clean -f && git checkout renamer^ 2>messages && test_i18ngrep "HEAD is now at 7329388" messages && - (test_line_count -gt 1 messages || test -n "$GETTEXT_POISON") && + ( + test_line_count -gt 1 messages || + test_have_prereq GETTEXT_POISON + ) && H=$(git rev-parse --verify HEAD) && M=$(git show-ref -s --verify refs/heads/master) && test "z$H" = "z$M" && diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh index 78d8c3783b..f46e21cfa0 100644 --- a/t/test-lib-functions.sh +++ b/t/test-lib-functions.sh @@ -755,16 +755,16 @@ test_cmp_bin() { # Use this instead of test_cmp to compare files that contain expected and # actual output from git commands that can be translated. When running -# under GETTEXT_POISON this pretends that the command produced expected +# under GIT_TEST_GETTEXT_POISON this pretends that the command produced expected # results. test_i18ncmp () { - test -n "$GETTEXT_POISON" || test_cmp "$@" + ! test_have_prereq C_LOCALE_OUTPUT || test_cmp "$@" } # Use this instead of "grep expected-string actual" to see if the # output from a git command that can be translated either contains an # expected string, or does not contain an unwanted one. When running -# under GETTEXT_POISON this pretends that the command produced expected +# under GIT_TEST_GETTEXT_POISON this pretends that the command produced expected # results. test_i18ngrep () { eval "last_arg=\${$#}" @@ -779,7 +779,7 @@ test_i18ngrep () { error "bug in the test script: too few parameters to test_i18ngrep" fi - if test -n "$GETTEXT_POISON" + if ! test_have_prereq C_LOCALE_OUTPUT then # pretend success return 0 diff --git a/t/test-lib.sh b/t/test-lib.sh index 897e6fcc94..ec77aa57d4 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -1104,15 +1104,8 @@ test -n "$USE_LIBPCRE1" && test_set_prereq LIBPCRE1 test -n "$USE_LIBPCRE2" && test_set_prereq LIBPCRE2 test -z "$NO_GETTEXT" && test_set_prereq GETTEXT -# Can we rely on git's output in the C locale? -if test -n "$GETTEXT_POISON" -then - GIT_GETTEXT_POISON=YesPlease - export GIT_GETTEXT_POISON - test_set_prereq GETTEXT_POISON -else - test_set_prereq C_LOCALE_OUTPUT -fi +test-tool gettext-poison && test_set_prereq GETTEXT_POISON +test-tool gettext-poison || test_set_prereq C_LOCALE_OUTPUT if test -z "$GIT_TEST_CHECK_CACHE_TREE" then