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

From: Tao Klerks via GitGitGadget <gitgitgadget@gmail.com>
Date: Jun 19, 2022, 16:10 UTC
Message-ID: <1226fbd3cafbe5202b576a2ca74f3cbf1f603f02.1655655027.git.gitgitgadget@gmail.com>
In-Reply-To: <pull.1257.v2.git.1655655027.gitgitgadget@gmail.com>

From: Tao Klerks <tao@klerks.biz>

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@klerks.biz>
---
 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