Re: [PATCH 19/21] t9003: become resilient to GETTEXT_POISON

From: Junio C Hamano <gitster@pobox.com>
Date: May 20, 2016, 16:39 UTC
Message-ID: <xmqqbn40fzu8.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAPig+cRo3tjt9N0YO8sNn90dL3dP0asfmKTr5rerS9YLO6QBtw@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 11 quoted lines

> [cc:+junio]
>
> Indeed, the sed seems superfluous. The output of the test command is:
>
>     git: 'lfg' is not a git command. See 'git --help'.
>
>     Did you mean this?
>         lgf
>
> And, the grep'd string, "lgf" only appears once, so grep alone should
> be sufficient to verify expected behavior.

We want to see the string appear after "Did you mean this?" and we do not want to be fooled by a future change in the early part of the message, which may contain a substring l-g-f that does not have anything to do with the alias we are looking for.

And the way you express "I do not care anything above this line" is to say "sed -e '1,/^that line/d'".

Of course, if you use this with POISON, you'd need to consider that "Did you mean this" would not be a good marker to identify where the introductory text we want to ignore ends. You'd need to find a different mechanism to exclude the introductory text if you want to retain the future-proofing the existing "sed -e" gave us.

Perhaps discarding up to the first blank line (i.e. assuming that we would not remove that blank, and also assuming that we will not rephrase "Did you mean this?") may be a good alternative.

Or assuming that the explanatory text would not begin its lines with a tab, i.e.

	grep '^	lgf$' actual

(the space between '^' and 'l' above is a TAB) without using test_i18ngrep?

I think I like that the best among what I can think of offhand.