File is always marked as modified in git status

[geotavros]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.15.1.windows.2
built from commit: 5d5baf91824ec7750b103c8b7c4827ffac202feb
sizeof-long: 4
machine: x86_64

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 6.1.7601]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: Nano
Path Option: BashOnly
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

No.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git clone https://bitbucket.org/reactivedropteam/reactivedrop_public_src_modified_file_bug.git
cd reactivedrop_public_src_modified_file_bug
git checkout weapon-gas-grenade
git status

• What did you expect to occur after running these commands?

Expect no modified files.

• What actually happened instead?

File reactivedrop/resource/ReactiveDrop_english.txt is marked as modified.

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

https://bitbucket.org/reactivedropteam/reactivedrop_public_src_modified_file_bug

weapon-gas-grenade branch was created earlier in the repository. After that we normalized line endings in the repository and pushed commits starting from d3ee316. We rebased weapon-gas-grenade onto reactivedrop_public branch(commit 17f7f12). And force pushed it.

I assume the problem is that weapon-gas-grenade adds this file ReactiveDrop_english.txt in lower case naming(reactivedrop_english.txt commit db5c411), but this file already existed in mixed case naming.

[geotavros]

I now actually think that this has nothing to do that the file is Unicode but that the mixed case is the issue. Probably the git rebase tool doesn't take into account that Windows is not case sensitive to file names. It could spot this and give me a conflict when rebasing or something.

I will try to solve this issue in our main repository. The fork mentioned above will remain unchanged in case somebody will want to take a look at this.

[tboegi]

As you said,
There are 2 files:
git ls-files -s --eol | grep -i ReactiveDrop_english.txt
100644 8e65e0be124d21af7bdcb77466aa758a3aacf72d 0 i/-text w/-text attr/text=auto reactivedrop/resource/ReactiveDrop_english.txt
100644 2aca8cbe2f8d590df4fc9f17b1084c14ce0f45f2 0 i/-text w/-text attr/text=auto reactivedrop/resource/reactivedrop_english.txt

This fixes it (for me):
$ git rm --cached reactivedrop/resource/reactivedrop_english.txt
$ git checkout reactivedrop/resource/ReactiveDrop_english.txt

[geotavros]

Thanks, after executing these commands git status now shows
deleted: reactivedrop/resource/reactivedrop_english.txt
And I can actually commit the deletion of this file. Before that I wasn't able to stage or stash this file at all.

[shiftkey]

I now actually think that this has nothing to do that the file is Unicode but that the mixed case is the issue. Probably the git rebase tool doesn't take into account that Windows is not case sensitive to file names. It could spot this and give me a conflict when rebasing or something

The root cause of this is case-insensitive filesystems (macOS and Windows both suffer from this). Git can't really help you out - there's some additional context here and here about it...

[tboegi]

@geotavros

I assume the problem is that weapon-gas-grenade adds this file ReactiveDrop_english.txt
in lower case naming(reactivedrop_english.txt commit db5c411),
but this file already existed in mixed case naming.

Did you create db5c411 on a Linux machine ?

[geotavros]

No, all commits were made from Windows. We only work on Windows for now.

[tboegi]

You got the files [Rr]eactivedrop_english.txt
in 2 different commits, see below.
How did you get these into your branch ?
(I suspect through a merge ?)
There are different things that can be done:
a) Review you Git workflow
b) Close this issue and after it is clear what the problem is and what happened, open a new one.

$ git log reactivedrop/resource/reactivedrop_english.txt
commit db5c411f48a80ed3b045cd790934cadfead68175 (HEAD)
Author: geotavros [email protected]
Date: Thu Dec 28 00:37:21 2017 +0200

Add equipment.res and reactivedrop_english.txt

---

$ git log reactivedrop/resource/ReactiveDrop_english.txt
commit 17f7f12dbabaaf5fb3503b048b77c0e3dd4584c9 (origin/reactivedrop_public)
Author: geotavros [email protected]
Date: Sat Dec 30 02:49:02 2017 +0200

Add basic mod template files

Developers can use these files to launch their compiled mod and add new
features to be submitted as pull requests.

[geotavros]

Above I wrote that this happened after rebase. I solved the issue by recreating a few commits and deleting one of the files.

Alright, I'll close this issue. But I still think that git tools(rebase and merge) could spot this and at least warn the Windows user about what is about happen. However it's up to git developers to decide ;)
Cheers

[tboegi]

Just a final comment:
If somebody should change Git, we need a receipe to reproduce the problem you had.
Do you think you can provide a simple example ?

[geotavros]

yes

[AraHaan]

I am experiencing this problem on one of my repositories with the file in git gui saying:

old mode 100755
new mode 100644

but after a forced hard reset it does not change anything for me and still says the working tree is not clean when it should be.

git version 2.19.2.windows.1

https://github.com/Elskom/Els_kom_new.git @dscho hopefully your latest release from 11 hours ago fixes the issue for me.

[PhilipOakley]

Is it the same problem of case sensitivity (by Git) relative to the insensitive Windows FS?

I.e. what are the true file names in the index and in the FS.

[AraHaan]

it is labeled as "Els_kom_Core/Classes/ZlibHelper.cs" on both index and windows FS.

[tboegi]

What does
git config core.filemode
give ?

[tms320]

I updated git to v.2.27 (Windows 10 x64). I use GUI tool "Git Extensions" to work with Git.

git --version --build-options
git version 2.27.0.windows.1
cpu: x86_64
built from commit: 907ab10
sizeof-long: 4
sizeof-size_t: 8

cmd.exe /c ver
Microsoft Windows [Version 10.0.18362.836]

type "C:\Program Files\Git\etc\install-options.txt"
Editor Option: Notepad++
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: ConHost
Git Pull Behavior Option: Merge
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled

I have the same "case-sensitive" problem.
If I clone the repo I get the following warning:

Pay attention to the first two letters of the file name and it's case: "На....ipt" (it is in russian).
When I open the cloned repo, I see that the repo has changes - the file is deleted:

But the file isn't deleted. His name only begins with "На..." (not "НА...").
Note: left ("white") part of screenshot is "Git Extensions" window, right ("black") part is Explorer opened in the repo's folder.
Deleting the file or renaming it to "НАконечник..." doesn't help.
Discarding changes doesn't help - the changes still remain.
If I press "Stage All" button then the staged changes stay empty i.e. I can't do commit.