Repo state broken due to mismatched file name casing during merge

Repo state broken due to mismatched file name casing during merge

[Rafał Grzybowski]

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.

What's different between what you expected and what actually happened?

The state should be clean. It looks like the merge process broke
something due to the casing.

Anything else you want to add:

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.28.0.windows.1
cpu: x86_64
built from commit: 77982caf269b7ee713a76da2bcf260c34d3bf7a7
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
uname: Windows 10.0 18363
compiler info: gnuc: 10.2
libc info: no libc information available
$SHELL (typically, interactive shell): <unset>

Re: Repo state broken due to mismatched file name casing during merge

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Repo state broken due to mismatched file name casing during merge

[Rafał Grzybowski]

Ok, I understand the behaviour now.
Thank you for your help :)