Re: [PATCH 1/1] t9115: Skip pathnameencoding=cp932 under HFS

From: Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>
Date: Mar 18, 2016, 02:15 UTC
Message-ID: <56EB64C2.4090405@f2.dion.ne.jp>
In-Reply-To: <56EA4230.7010501@web.de>

On 2016/03/17 14:35 +0900, Torsten Bögershausen wrote:

> On 2016-03-17 06.16, Torsten Bögershausen wrote:

...

> And the pathch is here:
> <https://github.com/tboegi/git/commit/866dfc192a0d4428aebfc7242f5134899b6dafd4>
> 
> Kazutoshi, could you re-test on your environment ?

The test 11,12 was skipped on my environment, too:

Show 8 quoted lines

> $ ./t9115-git-svn-dcommit-funky-renames.sh
> ok 1 - load repository with strange names
> ...
> ok 10 - git svn rebase works inside a fresh-cloned repository
> ok 11 # skip svn.pathnameencoding=cp932 new file on dcommit (missing FS_CP932 of UTF8,FS_CP932)
> ok 12 # skip svn.pathnameencoding=cp932 rename on dcommit (missing FS_CP932 of UTF8,FS_CP932)
> # passed all 12 test(s)
> 1..12

That's because the check for FS_CP932 runs under LC_ALL=C environment which affects how filenames are treated. See the comment on #11 for more details.

Setting LC_ALL before the check works for me.

 test_lazy_prereq FS_CP932 '
        # check whether FS allows filenames from cp932
+       prepare_a_utf8_locale
+       LC_ALL=$a_utf8_locale &&
+       export LC_ALL &&
        neq=$(printf "\201\202")

But it looks a bit strange to do "prepare_a_utf8_locale" here because it is done just before #11 now, though I think it does no harm.

I also don't understand the way of the check: Why don't you just touch
and test it, like this:
	touch "$neq" && test -e "$neq"
?

-- 
k_satoda