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

I'm one of the SourceTree developers (I develop the Mac version of the product, actually), so hopefully I can be of some help.

Windows machines convert CRLF to LF when committing and LF to CRLF when checking out. autocrlf makes sure everything is LF within the repository. The option text = auto is the one we're interested in though as it says in the docs:

When text is set to "auto", the path is marked for automatic end-of-line normalization. If git decides that the content is text, its line endings are normalized to LF on checkin.

So you see on checkin it will say "Hey, I need to normalise these line-endings because they're not in LF format, but in CRLF." and thus modifies your working copy to do the work it's expected to do. Usually on Mac/Linux you wouldn't need to normalise because everything is in LF, but Git will do a check because you might've checked out from a repository that was previously developed on Windows, or perhaps in an editor that was using CRLF instead of LF.

So in short, you'd probably want to re-commit all of those files as they should be in LF format, but also make sure autocrlf = true (edit, always to true!) in your Windows repository as it says in the docs:

If you simply want to have CRLF line endings in your working directory regardless of the repository you are working with, you can set the config variable "core.autocrlf" without changing any attributes.

Although imagine that previous quote was when setting autocrlf for a specific repository as well as globally.

Hopefully that's of some help, if not, feel free to ask more questions!

Here's a good SO post re: line endings: Why should I use core.autocrlf=true in Git?

EDIT

Based on the above answer we need to make sure of a few things here.

• That you've set the relevant git options in your .git/config
• If you want to keep CRLF line endings then set autocrlf=true
• If, when checking out your repository, you don't want your line endings to be automatically converted (causing all your files to be in the "modified" state immediately) then set the text option to unset. Add this option if a global git config has it set to a value you don't want.
• If you're working on both Windows and Mac for a project then it's best you have text=auto and make sure LF is used across the board. This is why problems like this creep in; because your git config's differ or because the initial project/git setup on Windows assumes CRLF when your Mac assumes LF.

I still don't understand it 100%, but for us the issue was the * text=auto in the .gitattribute file in the repository. I checked, and we for sure have core.autocrlf=true set in every place it can be set for my user on a Windows PC. I knew it wasn't a SourceTree issue either, as TortoiseGit and just Windows Git (msysgit) all had the same "issue" for this repository. Really odd behavior - I would clone the repo one time and immediately see 11 "different" files, then I would delete and start over and the next clone would have 14 "different" files.

Commenting out the * text=auto in the .gitattribute file of the repository fixed everything. Its almost like text=auto does not behave the same as autocrlf=true and the latter is disabled if the first is set in the .gitattribute file. But that is not what every guide online seems to indicate.

I added both following lines to the config file. The other thing I did was click on the "Staged Files" checkbox and then unclick it, and everything refreshed itself. Good luck.

text = auto autocrlf = true