summaryrefslogtreecommitdiff
path: root/t/t9129-git-svn-i18n-commitencoding.sh
AgeCommit message (Collapse)Author
2018-07-16t9000-t9999: fix broken &&-chainsEric Sunshine
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-svnEric Wong
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 ↵Elia Pinto
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 applicableJeff King
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-25tests: enclose $PERL_PATH in double quotesJunio C Hamano
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_PATHVincent van Ravesteijn
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 TAPÆvar Arnfjörð Bjarmason
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 detectionJunio C Hamano
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-31t9139 uses ancient, backwards-compatible iconv namesEric Wong
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 toolsEygene Ryabinkin
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-19t3900: use ancient iconv names for backward compatibilityBrandon Casey
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 testsJohannes Sixt
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2009-01-18git-svn: fix SVN 1.1.x compatibilityEric Wong
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-23t9129: skip the last three tests if UTF-8 locale is not availableMiklos Vajna
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 ↵Marcel Koeppen
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 configEric Wong
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>