Граф коммитов

10 Коммитов

Автор SHA1 Сообщение Дата
John Keeping 0be43dedbc t8005: avoid grep on non-ASCII data
GNU grep 2.23 detects the input used in this test as binary data so it
does not work for extracting lines from a file.  We could add the "-a"
option to force grep to treat the input as text, but not all
implementations support that.  Instead, use sed to extract the desired
lines since it will always treat its input as text.

While touching these lines, modernize the test style to avoid hiding the
exit status of "git blame" and remove a space following a redirection
operator.  Also swap the order of the expected and actual output
files given to test_cmp; we compare expect and actual to show how
actual output differs from what is expected.

Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-23 15:00:12 -08:00
Junio C Hamano f57a8715bc test prerequisites: eradicate NOT_FOO
Support for Back when bdccd3c1 (test-lib: allow negation of
prerequisites, 2012-11-14) introduced negated predicates
(e.g. "!MINGW,!CYGWIN"), we already had 5 test files that use
NOT_MINGW (and a few MINGW) as prerequisites.

Let's not add NOT_FOO and rewrite existing ones as !FOO for both
MINGW and CYGWIN.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-21 15:42:34 -07:00
Karsten Blees 32f4cb6cee MinGW: disable legacy encoding tests
On Windows, all native APIs are Unicode-based. It is impossible to pass
legacy encoded byte arrays to a process via command line or environment
variables. Disable the tests that try to do so.

In t3901, most tests still work if we don't mess up the repository encoding
in setup, so don't switch to ISO-8859-1 on MinGW.

Note that i18n tests that do their encoding tricks via encoded files (such
as t3900) are not affected by this.

Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-21 09:39:57 -07:00
Junio C Hamano 6517452d7a Merge branch 'maint'
* maint:
  t8005: Nobody writes Russian in shift_jis

Conflicts:
	t/t8005-blame-i18n.sh
2009-07-25 02:16:25 -07:00
Junio C Hamano 54bc13ce53 t8005: Nobody writes Russian in shift_jis
The second and third tests of this script expected that Russian strings
are converted between ISO-8859-5 and Shift_JIS in the "blame --porcelain"
format output correctly.

Sure, many platforms may convert between such a combination, but that is
only because one of the base character set of Shift_JIS, JIS X 0208,
defines codepoints for Russian characters (among others); I do not think
anybody uses Shift_JIS when seriously writing Russian, and it is perfectly
understandable if iconv() libraries on some platforms fail converting
between this combination, as it does not matter in reality.

This patch changes the test to verify Japanese strings are converted
correctly between EUC-JP and Shift_JIS in the same procedure.  The point
of the test is not about verifying the platform's iconv() library, but to
see if "git blame" makes correct iconv() library calls when it should.

We could instead use ISO-8859-5 and KOI8-R as the combination, because
they are both meant to represent Russian, in order to make this test
meaningful on more platforms, but we already use Shift_JIS vs EUC-JP
combinations to test other programs in our test suite, so this combination
is safer from the point of view of the portability.  Besides, I do not
read nor write Russian; sorry ;-)

This change allows tests to pass on my (friend's) Solaris 5.11 box.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-25 02:14:56 -07:00
Brandon Casey ed43bc8c4c t8005: fix typo, it's ISO-8859-5, not KOI8-R
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-27 20:24:55 -07:00
Brandon Casey bb43414b37 t8005: convert CP1251 character set to ISO8859-5
On IRIX 6.5 CP1251 is unknown, but WIN1251 (which seems to be a
non-standard name) is known.  On Solaris 10, the opposite is true.  Solaris
also knows CP1251 as WINDOWS-1251, but this too is not recognized on IRIX.
I could not find a name that both platforms recognized for this character
set.

An alternative character set which covers the same alphabet seems to be the
ISO8859-5 character set.  Both platforms support this character set, so use
it instead.

This allows t8005.4 to pass on Solaris 7, and part of the test to pass on
IRIX. (My IRIX can't convert SJIS to UTF-8 :(

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-22 22:41:04 -07:00
Brandon Casey bdb0a7e4e4 t8005: use more portable character encoding names
Some platforms do not have an extensive list of alternate names for
character encodings.

Solaris 7 does not know about shift-jis, but does know SJIS.  It also does
not know that utf-8 and UTF-8 refer to the same encoding.

With the above in mind, the following conversions were performed:

      utf-8 --> UTF-8
  shift-jis --> SJIS

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-22 22:40:22 -07:00
Brandon Casey 0b05dc2b7e t8005: use egrep when extended regular expressions are required
Not all versions of grep understand backslashed extended regular
expressions.  Possibly only gnu grep does.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-06 11:48:58 -07:00
Alexander Gavrilov 69cd8f6342 builtin-blame: Reencode commit messages according to git-log rules.
Currently git-blame outputs text from the commit messages
(e.g. the author name and the summary string) as-is, without
even providing any information about the encoding used for
the data. It makes interpreting the data in multilingual
environment very difficult.

This commit changes the blame implementation to recode the
messages using the rules used by other commands like git-log.
Namely, the target encoding can be specified through the
i18n.commitEncoding or i18n.logOutputEncoding options, or
directly on the command line using the --encoding parameter.

Converting the encoding before output seems to be more
friendly to the porcelain tools than simply providing the
value of the encoding header, and does not require changing
the output format.

If anybody needs the old behavior, it is possible to
achieve it by specifying --encoding=none.

Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-21 14:09:34 -07:00