On 2020-09-02 at 16:26:27, Rafał Grzybowski wrote:
> What did you do before the bug happened? (Steps to reproduce your issue)
> 
> mkdir repo
> cd repo
> 
> git init
> 
> "sample file" > file.txt
> git add file.txt
> git commit -m "Added file.txt"
> 
> 
> git checkout -b other_branch
> echo other file > other_file.txt
> git add other_file.txt
> git commit -m "Added other_file.txt"
> 
> git checkout master
> echo Other file > Other_file.txt
> git add Other_file.txt
> git commit -m "Added Other_file.txt"
> 
> git merge other_branch
> git status
> 
> What did you expect to happen? (Expected behavior)
> 
> A clean state, no unstaged changes.
> 
> What happened instead? (Actual behavior)
> 
> There is always an unstaged file other_file.txt which case changes if
> I try to discard and the unstaged change stays.
> If I try to delete the file, I get two unstaged file removal changes.

Git always preserves the case of files internally.  However, the default
configuration on Windows does not.  When you performed this merge, you
ended up with two files, but it's not possible to write both of them
into the working tree.  Since they are not the same, when Git checks the
status of one of the files, it finds it to be modified.

The solution here is to do "git rm --cached Other_file.txt" followed by
a commit.  That removes the file from the index but doesn't touch the
working tree.  In Windows 10, you can also set a directory to be case
sensitive, which should fix this if you do a "git checkout .".

This isn't a bug in Git; Git doesn't know about file name encodings, and
even if it only handled Unicode file names, it's impossible to correctly
perform locale-insensitive case folding, so Git doesn't even try.
-- 
brian m. carlson: Houston, Texas, US