Re: [PATCH v1 1/2] t0050: ls-files path fails if path of workdir is NFD

[Junio C Hamano <gitster@pobox.com>]

tboegi@web.de writes:

> From: Torsten Bögershausen <tboegi@web.de>
>
> Add a test case for this bug report, slightly edited and shortened:
>
> ls-files path' fails if absolute path of workdir contains NFD (macOS)
> On macOS, 'git ls-files path' does not work (gives an error)
> if the absolute 'path' contains characters in NFD (decomposed).
> I guess this is a (minor) bug of git.
>
> $ cd /somewhere         # some safe place, /tmp or ~/tmp etc.
> $ mkdir $'u\xcc\x88'    # ü in NFD
> $ cd ü                  # or cd $'u\xcc\x88' or cd $'\xc3\xbc'
> $ git init
> $ git ls-files $'/somewhere/u\xcc\x88'   # NFD
>   fatal: /somewhere/ü: '/somewhere/ü' is outside repository at '/somewhere/ü'
> $ git ls-files $'/somewhere/\xc3\xbc'    # NFC
> (the same error as above)
>
> In the 'fatal:' error message, there are three ü;
> the 1st and 2nd are in NFC, the 3rd is in NFD.
>
> The added test case here follows the error description,
> with the exception that the 'ü' is replaced by an 'ä',
> which we already have as NFD and NFC in t0050.
> A fix will be done in the next commit.

That will break bisection.  I think combining the two commits into
one would make sense for a small change like this, consisting a
focused and straight-forward fix plus a clean and concise test.

> Reported-by: Jun T <takimoto-j@kba.biglobe.ne.jp>
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
>  t/t0050-filesystem.sh | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
> index 325eb1c3cd..bb85ec38cb 100755
> --- a/t/t0050-filesystem.sh
> +++ b/t/t0050-filesystem.sh
> @@ -156,4 +156,16 @@ test_expect_success CASE_INSENSITIVE_FS 'checkout with no pathspec and a case in
>  	)
>  '
>
> +test_expect_success 'git ls-files under NFD' '
> +	(
> +		mkdir somewhere &&
> +		mkdir somewhere/$aumlcdiar &&

Would a single "mkdir -p" suffice?

		mkdir -p "somewhere/$aumlcdiar" &&

> +		mypwd=$PWD &&
> +		cd somewhere/$aumlcdiar &&
> +		git init &&
> +		git ls-files "$mypwd/somewhere/$aumlcdiar"  2>err &&

We do not control what is in "$mypwd".  Can it have funny characters
that can confuse Git?  Quoting the path with a pair of double quotes
protects the shell from getting confused with $IFS whitespaces, but
we may want to protect the pathspec handing in Git with something
like

	git --literal-pathspecs ls-files "..." 

here.

> +		>expected &&
> +		test_cmp expected err
> +	)
> +'
>  test_done
> --
> 2.41.0.394.ge43f4fd0bd