tboegi@xxxxxx writes: > From: Torsten Bögershausen <tboegi@xxxxxx> > > 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@xxxxxxxxxxxxxxxxx> > Signed-off-by: Torsten Bögershausen <tboegi@xxxxxx> > --- > 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
