SourceTree App says uncommitted changes even for newly-cloned repository - what could be wrong?

Question

A remote git repository is just cloned to a local box using Atlassian SourceTree. Even no files have really been modified in the work tree, Atlassian lists

Answer 1

Just ran into this issue. A fresh clone would pull several files that were not only uncommitted, but also had many lines of real new code. git reflog showed nothing, it wasn't an actual commit so a detached HEAD was out of question.

After about an hour of investigation we found the cause. One of our *nix developers had, most likely mistakenly, added files to a folder that was the same name as the one intended but had different capitalization. *nix environments were able to handle this new folder easily, but Windows (due to its case-insensitive nature) merged the two folders.

So, for example, if you have two folders, test and Test, each with a file.txt inside and those two file.txt files aren't identical, then Windows will actually copy/replace one of them (not sure which order it clones folders in) thus "changing" the file and creating uncommitted changes on "Test/file.txt" directly after a fresh install.

Example:

test/
--file.txt (with contents of "This is a commit")

Test/
--file.txt (with contents of "This is a commit with some changes")

This will always show new uncommitted changes consisting of adding the words " with some changes" to Test/file.txt when cloning on a Windows machine while *nix-based machines won't have an issue.

This doesn't necessarily address the OP's issue, but directly relates to the question in the title. Hopefully that helps someone out there.