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
Attachment:
signature.asc
Description: PGP signature
