[PATCH v3 2/3] reset: new failing test for reset of case-insensitive duplicate in index

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Tao Klerks <tao@xxxxxxxxxx>

On case-insensitive filesystems, where core.ignorecase is normally set,
the index is still case-sensitive, and surprising outcomes are possible
when the index contains states that cannot be represented on the file
system.

Add an "expect_failure" test to illustrate one such situation, where two
files differing only in case are in the index, and a "reset --hard" ends
up creating an unexpected worktree change.

Signed-off-by: Tao Klerks <tao@xxxxxxxxxx>
---
 t/t7104-reset-hard.sh | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/t/t7104-reset-hard.sh b/t/t7104-reset-hard.sh
index cf9697eba9a..55050ac831e 100755
--- a/t/t7104-reset-hard.sh
+++ b/t/t7104-reset-hard.sh
@@ -44,4 +44,15 @@ test_expect_success 'reset --hard did not corrupt index or cache-tree' '
 
 '
 
+test_expect_failure CASE_INSENSITIVE_FS 'reset --hard handles index-only case-insensitive duplicate' '
+	test_commit "initial" file1 "initial commit with file1" initial &&
+	file1blob=$(git rev-parse :file1) &&
+	git update-index --add --cacheinfo 100644,$file1blob,File1 &&
+
+	# reset --hard accidentally leaves the working tree with a deleted file.
+	git reset --hard &&
+	git status --porcelain -uno >wt_changes_remaining &&
+	test_must_be_empty wt_changes_remaining
+'
+
 test_done
-- 
gitgitgadget




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux