Changing branches in git mistakenly results in modified files

Question

I am using git (1.8.3) on Windows. If I clone a repo from github then immediately checkout a different existing branch on that repo, git detects modified files. Usually. Sometimes it doesn't. And the diff on all of the modified files comes back identical (including line endings). This problem has been observed on 2 different repos on at least 4 different PCs among my team.

And it's not always the same files, but it's almost always one of a few subsets of files in the rep. For example, sometimes it's the same 5 files in the root of the repo, sometimes it's the same 93 files in one particular folder, sometimes it's the same 16 files in a different folder.

Once git has marked the files as modified, if I revert or stash them, they are immediately marked as modified again, which makes it impossible to switch back and forth between branches.

I have the feeling it's related to line endings, but I've already added the recommended .gitattributes file and renormalized each branch, but I still have these sporadic problems. Another possibility I've thought of is merging between branches somehow messed up the renormalization I did, but I don't know how to test that theory.

We all have core.autocrlf=true as we are all on Windows. Here is our .gitattributes

# Auto detect text files and perform LF normalization
* text=auto

# Custom for Visual Studio
*.cs      diff=csharp
*.sln     merge=union
*.csproj  merge=union
*.sqlproj merge=union
*.html    text diff=html
*.css     text
*.js      text
*.ejs     text
*.sql     text

# Standard to msysgit
*.doc     diff=astextplain
*.DOC     diff=astextplain
*.docx    diff=astextplain
*.DOCX    diff=astextplain
*.pdf     diff=astextplain
*.PDF     diff=astextplain

Answer 1

There are two situations where I've seen this sort of thing happen:

• Line endings and all the crazy options Git has for trying to deal with those across platforms. (I don't use these features at all myself, and I prefer to store and work with files all with consistent LF line endings, including on Windows.)

• Repositories that have two or more files whose names different only in case. For example, readme.txt and ReadMe.txt. Git on Windows has great difficulty dealing with these situations, because there is only one underlying file that can be accessed through two different names.

Answer 2

Never set core.autocrlf to true, always to false.

It is that simple: it is a global setting with unintended consequences.

If you have certain type of documents you want to manage in term of eol, do so only through .gitattributes files and core.eol directives.

That means: get rid first of all directory changing automatically eol (like your * text=auto), push that modification back to the upstream repo, and see if the issue persists.

Then, and only then, re-introduce those directives, not for every files (not for '*'), but only for files you absolutely want eol normalized.
And check if that works.