Git: no changes in this file have been detected, or it is a binary file

Question

I have refreshed a sandbox a few weeks ago and since then all the files in the repository are "marked" like if there was a difference but they are not, showing the message: No changes in this file have been detected, or it is a binary file.

What it make it more weird, is that if I do a change in the file, it shows as normal, but once i commit, if i refresh this time from the IDE it will show back again like changes were made.

As I am using source tree I have follow this instruction but I was unsuccessful (increasing file size, saving the file as UTF-8) https://community.atlassian.com/t5/Sourcetree-questions/Unable-to-detect-changes-in-asmx-vb-file-in-the-latest-release/qaq-p/629333

Have anyone encounter the same issue?

Answer 1

It sounds like you're using all the default options of the tools you installed, you're using Windows, and the Force.com IDE. The main problem with the default settings is that the API uses the LF line endings, the Force.com API uses CRLF line endings by default in Windows, and Git uses core.autocrlf=true in Windows.

What this means is that the line endings in your repo are LF, but when you modify the files in the Force.com IDE, they get rewritten as CRLF, which Git then automatically tries to convert back to LF, showing the "no changes detected" message. The same problem occurs if you refresh, because the Force.com IDE is using CRLF, but the API uses LF.

This is one of those cases where too many tools are trying to be helpful all at once. To fix this, you should set your settings to minimize the chaos of your repo. We can do this in two simple steps.

Force.com IDE

The Force.com IDE likes to use the OS's default line endings. Let's fix this in Window > Preferences > General > Workspace, change Text File Encoding to UTF-8, and change New Text File Line Delimiter to Other: Unix.

Git

Configure git to use LF endings:

git config core.autocrlf false
git config core.eol lf

This will make sure that you're consistently using LF everywhere instead of CRLF, which should minimize your false positives on changes.