On Sun, Jan 10, 2021 at 07:59:50PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Sun, Jan 10 2021, SZEDER Gábor wrote:
>
> > On Tue, Jan 05, 2021 at 08:42:41PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >> We need to provide GIT_TEST_GETTEXT_POISON=false here because the
> >> "invalid object type" error is emitted by
> >> parse_loose_header_extended(), which has that message already marked
> >> for translation. Another option would be to use test_i18ngrep, but I
> >> prefer always running the test, not skipping it under gettext poison
> >> testing.
> >
> > This is fairly unconvincing. Why do you prefer it that way? What is
> > so special in these tests of 'git mktags' that could possibly warrant
> > this special treatment WRT gettext poisoning, as opposed to the other
> > ~1500 invocations of test_i18n{grep,cmp}?
>
> You prodded me about this and Johannes also did off-list. So given that
> this is already in "next" I think it's best to let usage in this mktag
> series land as-is.
>
> I promise I'll follow-up with something to (at least start to) fix this
> generally one way or the other on "master" after that. It's a trivial
> part of this particular series.
>
> I.e. either document & migrate away from test_i18ngrep (mostly, in some
> cases it's still convenient), or git rid of this and the few existing
> GIT_TEST_GETTEXT_POISON=false uses.
>
> Anyway, as both the initial author of this poison facility & of its
> current runtime incarnation in git.git, some context on it:
>
> The need for test_i18ngrep was always a wart. When I submitted the
> initial i18n patches a big selling point at the time to a (rightly so)
> skeptical audience on the Git ML was that it could almost entirely be
> turned off at compile-time, and that we had something in place to make
> sure we didn't introduce plumbing bugs by overtranslating.
>
> For a while the mass-i18n patches were about as noisy on-list as the
> sha256 conversion patches were in more recenty memory.
>
> So if you look through the history you'll see that first we skipped
> whole tests with the C_LOCALE_OUTPUT prereq, and then test_i18ngrep was
> a more granular way to do that:
>
> git some-command >output &&
> test_i18ngrep "c locale string" output
>
> But since 6cdccfce1e0 (i18n: make GETTEXT_POISON a runtime option,
> 2018-11-08) this hasn't been needed. But yes, we have a bit under 10
> years of test_i18ngrep usage in the test suite now.
>
> But that stuff is the wart, and purely a historical artifact of this
> having once been compile-time only. We don't do this sort of thing with
> any other GIT_TEST_* option, e.g. we have tests like:
>
> t/t5512-ls-remote.sh: GIT_TEST_PROTOCOL_VERSION=0 git ls-remote --symref --heads . >actual &&
> t/t5512-ls-remote.sh- test_cmp expect actual &&
>
> Not:
>
> t/t5512-ls-remote.sh: git ls-remote --symref --heads . >actual &&
> t/t5512-ls-remote.sh- test_protocolv0cmp expect actual &&
>
> Because that doesn't make sense. If we know we're testing protocol v0
> here why wouldn't we just pass that as a parameter in the test? Same for
> GIT_TEST_GETTEXT_POISON=false.
I think it's the comparison of GIT_TEST_GETTEXT_POISON and
GIT_TEST_PROTOCOL_VERSION that doesn't make sense in the first place.
For the sake of users who might be stuck on Git version not yet
understanding protocol v2 or have to connect to a v0-only remote, we
must make sure that both v0 and v2 protocols work, so a simple
'make test' must exercise both. Since protocol v2 is the default
nowadays, we need a way to tell some tests to use v0 instead, and
setting GIT_TEST_PROTOCOL_VERSION=0 ended up our standard way to do
that. Besides, the uses of GIT_TEST_PROTOCOL_VERSION is quite
contained, as it is set in only 34 times in 13 test scripts.
GETTEXT_POISON is purely a developer aid (of questionable usefulness
as you explained above), no end user would ever see it, and yet the
test_i18n* functions are used ~1500 times in 250+ test scripts. I
sure dont't want to see 1500+ uses of 'GIT_TEST_GETTEXT_POISON=false
git cmd...'. Besides, what would be the purpose of
'GIT_TEST_GETTEXT_POSION=true make test' if it would eventually be
overriden all over the place?
> I have also wondered if a better approach at this point isn't to just
> remove the thing entirely. We're just doing incremental i18n-ization at
> this point, so the odds that it's catching accidental plumbing
> translations is rather low compared to 2011-era git.git.
I wouldn't mind seeing it go... well, I think I would welcome it,
actually :) I can only recall cases where a failure of the
GETTEXT_POISON CI job was resolved by another replacement of 'grep'
with 'test_i18ngrep', but I don't seem to remember a case where we
decided that "Nah, this message should not have been translated in the
first place".
I would, however, really miss the error reporting of 'test_i18ngrep',
though, i.e. that it shows the contents of the file when it doesn't
find a match.
