summaryrefslogtreecommitdiff
path: root/t/t8005-blame-i18n.sh
AgeCommit message (Collapse)AuthorFilesLines
2009-07-25Merge branch 'maint'Libravatar Junio C Hamano1-13/+13
* maint: t8005: Nobody writes Russian in shift_jis Conflicts: t/t8005-blame-i18n.sh
2009-07-25t8005: Nobody writes Russian in shift_jisLibravatar Junio C Hamano1-13/+13
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-05-27t8005: fix typo, it's ISO-8859-5, not KOI8-RLibravatar Brandon Casey1-1/+1
Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-22t8005: convert CP1251 character set to ISO8859-5Libravatar Brandon Casey1-13/+13
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-22t8005: use more portable character encoding namesLibravatar Brandon Casey1-3/+3
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-06t8005: use egrep when extended regular expressions are requiredLibravatar Brandon Casey1-4/+4
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>
2008-10-21builtin-blame: Reencode commit messages according to git-log rules.Libravatar Alexander Gavrilov1-0/+92
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>