On Sun, Jan 21, 2018 at 3:33 AM, brian m. carlson
<sand...@crustytoothpaste.net> wrote:
> We recently introduced a regression in cloning repositories onto
> case-insensitive file systems where the repository contains multiple
> files differing only in case. In such a case, we would segfault. This
> segfault has already been fixed (repository: pre-initialize hash algo
> pointer), but it's not the first time similar problems have arisen.
> Introduce a test to catch this case and ensure the behavior does not
> regress.
>
> Signed-off-by: Eric Sunshine <sunsh...@sunshineco.com>
> Signed-off-by: brian m. carlson <sand...@crustytoothpaste.net>
> ---
> t/t5601-clone.sh | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> I've verified that the test does fail without the patch on a vfat file
> system. However, many other tests also fail on a vfat file system on
> Linux, so unfortunately that doesn't look like a viable testing strategy
> going forward.
vfat is not very UNIXy. I suspect we need a bunch of tweaks that
cygwin/mingw uses to make the test suite pass. There are other
case-insensitive filesystems on linux though. JFS (with "mkfs.jfs -O"
to make it case-insensitive) seems to pass the test suite and crash
git without your fix so it's a good candidate if someone wants to test
this behavior on linux in future. HFS+ fails some unicode test in
t0050 and I didn't check further.
> +test_expect_success 'clone on case-insensitive fs' '
We have CASE_INSENSITIVE_FS prereq. Should we use it here? I know it
does not harm running this test on case-sensitive filesystem, but the
prereq could be useful for grepping.
> + o=$(git hash-object -w --stdin </dev/null | hex2oct) &&
> + t=$(printf "100644 X\0${o}100644 x\0${o}" |
> + git hash-object -w -t tree --stdin) &&
> + c=$(git commit-tree -m bogus $t) &&
> + git update-ref refs/heads/bogus $c &&
> + git clone -b bogus . bogus
> +'
> +
> test_done
--
Duy
