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
