summaryrefslogtreecommitdiff
path: root/t/t9129-git-svn-i18n-commitencoding.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-06-08t: use user-specified utf-8 locale for testing svnLibravatar Đoàn Trần Công Danh1-2/+2
In some test-cases, UTF-8 locale is required. To find such locale, we're using the first available UTF-8 locale that returned by "locale -a". However, the locale(1) utility is unavailable on some systems, e.g. Linux with musl libc. However, without "locale -a", we can't guess provided UTF-8 locale. Add a Makefile knob GIT_TEST_UTF8_LOCALE and activate it for linux-musl in our CI system. Rename t/lib-git-svn.sh:prepare_a_utf8_locale to prepare_utf8_locale, since we no longer prepare the variable named "a_utf8_locale", but set up a fallback value for GIT_TEST_UTF8_LOCALE instead. The fallback will be LC_ALL, LANG environment variable, or the first UTF-8 locale from output of "locale -a", in that order. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-16t9000-t9999: fix broken &&-chainsLibravatar Eric Sunshine1-1/+1
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22git-svn: hoist out utf8 prep from t9129 to lib-git-svnLibravatar Eric Wong1-11/+1
We will be reusing this in t9115. Suggested-by: Kazutoshi Satoda <k_satoda@f2.dion.ne.jp> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2016-01-12t9129-git-svn-i18n-commitencoding.sh: use the $( ... ) construct for command ↵Libravatar Elia Pinto1-2/+2
substitution The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-29t: use perl instead of "$PERL_PATH" where applicableLibravatar Jeff King1-1/+1
As of the last commit, we can use "perl" instead of "$PERL_PATH" when running tests, as the former is now a function which uses the latter. As the shorter "perl" is easier on the eyes, let's switch to using it everywhere. This is not quite a mechanical s/$PERL_PATH/perl/ replacement, though. There are some places where we invoke perl from a script we generate on the fly, and those scripts do not have access to our internal shell functions. The result can be double-checked by running: ln -s /bin/false bin-wrappers/perl make test which continues to pass even after this patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-24tests: enclose $PERL_PATH in double quotesLibravatar Junio C Hamano1-1/+1
Otherwise it will be split at a space after "Program" when it is set to "\\Program Files\perl" or something silly like that. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-12t: Replace 'perl' by $PERL_PATHLibravatar Vincent van Ravesteijn1-1/+1
GIT-BUILD-OPTIONS defines PERL_PATH to be used in the test suite. Only a few tests already actually use this variable when perl is needed. The other test just call 'perl' and it might happen that the wrong perl interpreter is used. This becomes problematic on Windows, when the perl interpreter that is compiled and installed on the Windows system is used, because this perl interpreter might introduce some unexpected LF->CRLF conversions. This patch makes sure that $PERL_PATH is used everywhere in the test suite and that the correct perl interpreter is used. Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-25tests: Skip tests in a way that makes sense under TAPLibravatar Ævar Arnfjörð Bjarmason1-1/+1
SKIP messages are now part of the TAP plan. A TAP harness now knows why a particular test was skipped and can report that information. The non-TAP harness built into Git's test-lib did nothing special with these messages, and is unaffected by these changes. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-02t9129: fix UTF-8 locale detectionLibravatar Junio C Hamano1-7/+13
The UTF-8 prerequisite test checked explicitly for en_US.utf8 in the output from "locale -a", but the tests that are actually protected by the prerequisite were asking LC_ALL=en_US.UTF-8 from the system. This inconsistency leads the tests to fail on platforms that do not know both en_US.UTF-8 and en_US.utf8 (thanks you, Yann Droneaud, for bringing this up with an initial patch). Instead, pick a locale with ".UTF-8" (with or without hyphen, spelled in either upper or lowercase) in its name from "locale -a" output, and use it for running the test. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-30t9139 uses ancient, backwards-compatible iconv namesLibravatar Eric Wong1-5/+5
This resolves a semantic conflicts early to work with 5ae93df (t3900: use ancient iconv names for backward compatibility, 2009-05-18). Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-21git-svn testsuite: use standard configuration for Subversion toolsLibravatar Eygene Ryabinkin1-1/+1
I have tweaked configuration in my ~/.subversion directory, namely I am running auto-properties and automatically adding '$Id$' expansion to every file. This choke the last test named 'proplist' from t9101-git-svn-props.sh, because one more property, svn:keywords is automatically added. I had just wrapped svn invocation with the svn_cmd that specifies empty directory via --config-dir argument. Since the latter is the global option, it should be recognized by all svn subcommands, so no regressions will be introduced. Now svn_cmd is used everywhere, not just in the failed test module: this should guard us from the future clashes with user-defined configuration tweaks. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-05-18t3900: use ancient iconv names for backward compatibilityLibravatar Brandon Casey1-5/+5
Some old iconv implementations do not have many alternate names and/or do not match character encoding names case insensitively. These implementations can not tell that utf-8 and UTF-8 are the same encoding and fail when trying to do the conversion. So use the old names, which modern implementations still support. The following conversions were performed: utf-8 --> UTF-8 ISO-8859-1 --> ISO8859-1 EUCJP --> eucJP Also update t9129 and t9500 which make use of the test files in t/t3900. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22t9100, t9129: Use prerequisite tags for UTF-8 testsLibravatar Johannes Sixt1-10/+12
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2009-01-18git-svn: fix SVN 1.1.x compatibilityLibravatar Eric Wong1-2/+11
The get_log() function in the Perl SVN API introduced the limit parameter in 1.2.0. However, this got discarded in our SVN::Ra compatibility layer when used with SVN 1.1.x. We now emulate the limit functionality in older SVN versions by preventing the original callback from being called if the given limit has been reached. This emulation is less bandwidth efficient, but SVN 1.1.x is becoming rarer now. Additionally, the --limit parameter in svn(1) uses the aforementioned get_log() functionality change in SVN 1.2.x. t9129 no longer depends on --limit to work and instead uses Perl to parse out the commit message. Thanks to Tom G. Christensen for the bug report. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2008-12-22t9129: skip the last three tests if UTF-8 locale is not availableLibravatar Miklos Vajna1-13/+17
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-26t9129-git-svn-i18n-commitencoding: Make compare_svn_head_with() compatible ↵Libravatar Marcel Koeppen1-1/+1
with OSX sed The sed call used in compare_svn_head_with() uses the + quantifier, which is not supported in the OSX version of sed. It is replaced by the equivalent \{1,\}. Signed-off-by: Marcel Koeppen <git-dev@marzelpan.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-06git-svn: respect i18n.commitencoding configLibravatar Eric Wong1-0/+80
SVN itself always stores log messages in the repository as UTF-8. git always stores/retrieves everything as raw binary data with no transformations whatsoever. To interact with SVN, we need to encode log messages as UTF-8 before sending them to SVN, as SVN cannot do it for us. When retrieving log messages from SVN, we also need to (attempt to) reencode the UTF-8 log message back to the user-specified commit encoding. Note, handling i18n.logoutputencoding for "git svn log" also needs to be done in a future change. Also, this change only deals with the encoding of commit messages and nothing else (path names, blob content, ...). In-Reply-To: <8b168cfb0810282014r789ac01dnec51824de1078f0@mail.gmail.com> James North <tocapicha@gmail.com> wrote: > Hi, > > I'm using git-svn on a system with ISO-8859-1 encoding. The problem is > when I try to use "git svn dcommit" to send changes to a remote svn > (also ISO-8859-1). > > Seems like git-svn is sending commit messages with utf-8 (just a > guessing...) and they look bad on the remote svn log. E.g. "Ca?\241a > de cami?\243n" > > I have tried using i18n.commitencoding=ISO-8859-1 as suggested by the > warning when doing "git svn dcommit" but messages still are sent with > wrong encoding. Signed-off-by: Eric Wong <normalperson@yhbt.net>