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.
I didn't include an object ID for the commit referenced simply because I
didn't see one yet and I didn't want to insert a local one that wouldn't
work for anyone else.
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 0f895478f0..53b2dda9d2 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -611,4 +611,17 @@ test_expect_success 'GIT_TRACE_PACKFILE produces a usable
pack' '
git -C replay.git index-pack -v --stdin <tmp.pack
'
+hex2oct() {
+ perl -ne 'printf "\\%03o", hex for /../g'
+}
+
+test_expect_success 'clone on case-insensitive fs' '
+ 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
