Sourcetree sees new file when code doesn't change but timestamp does

[David Sals]

There are times when I need to pull down the latest files from my production server and push changes into GIT. When I pull the files, everything in my local GIT repo gets overwritten - mostly with the exact same files (name, code, location - everything is the same except the timestamp).

Even though 95% of the files are exactly the same as what was there before, Sourcetree seems to consider those file to have changed. In the merge screen I can see the complete code for that file highlighted in red (old) followed by the exact same code highlighted in green (new). There are no differences in the old and new code.

Does this have to happen? It makes these pushes to GIT relatively useless, as there's no way to see what actually has changed. Is there any way to force Sourcetree to just look at the code and not the timestamp (or whatever it uses to determine it's a different file)?

[QwazyWabbit · Accepted solution]

I have only seen this happen when dealing with Linux/OS X line endings vs Windows. Visual Studio wants consistent endings and will offer to convert them if it  finds mixed line endings in a file. This leads to whole files looking changed within SourceTree. I've found that keeping to CRLF in Windows and LF in OS X and pushing/pulling via SourceTree on Windows will eventually straighten itself out. Then it doesn't seem to matter whether I push/pull on OS X via SourceTree or Xcode natively. 

[Tim Crall]

yep, line endings for sure

[Seth]

You might also check your git settings to see if Git is doing something strange with line endings or other whitespace: https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#Formatting-and-Whitespace

[David Sals]

Thanks everyone! I will investigate the line ending issue.

[QwazyWabbit]

I've never touched the core.autocrlf on any of my systems. Perhaps this is why a mixed line ending file sneaks in once in a while. I'm writing mixed-platform so I'm constantly alternating between Xcode and Visual Studio.

Query git with git config --global core-autocrlf and if it returns a blank line it's not set.

If it's set, clear it with git config --unset --global core-autocrlf for "default" behavior.

[thinsoldier]

What does that config option do exactly? I had the same problem but didn't understand what I should do so I decided to enforce manually only unix line endings at all times no matter which OS the project is being edited on.

[QwazyWabbit]

The documentation is not clear and when I am confronted with that situation I am inclined to not mess with default settings.

As I understand it, setting to true on Windows systems causes git to convert LF to CRLF endings automatically when checking out (or presumably, pulling) code. (I have no idea what it does if the file is not text and the cited documentation is deficient in this regard.)

The documentation is also deficient about what the line endings will be in a remote repository when it is set to true on a Windows client and unset on a Linux or Mac client.

Setting it to false causes GIT to ignore all line ending styles, keeping CRLF endings in the repository.

Here's another deficiency: which repository? The term repository applies equally to a local clone and a remote repository on a foreign system. Exactly which repository is it talking about?

Then there's the third option: input.

This keeps line endings as they were input and leaves them untouched on commit.

Here's what git help config has to say:

core.autocrlf

Setting this variable to "true" is almost the same as setting the text attribute to "auto" on all files except that text files are not guaranteed to be normalized: files that contain CRLF in the repository will not be touched. Use this setting if you want to have CRLF line endings in your working directory even though the repository does not have normalized line endings. This variable can be set to input, in which case no output conversion is performed.

________

All this being said, I checked my ~/.gitconfig in Mac and C:\users\username\.gitconfig and I found no setting for core.autocrlf in either one so I left them unset.

I set Xcode text edit to (default, I think), UTF-8, LF endings, convert on save.

I set Visual Studio to auto detect UTF-8, detect external changes, auto-load on change, check for consistency when loading, save documents as Unicode when data cannot be saved in codepage.

This seems to work for me. I have LF on Linux/Mac, CRLF on Windows. When VS sees a mixed line ending it prompts for conversion and I let it convert the file to consistent state, then save the file and view the diff.

I can commit from Xcode or SourceTree on Mac and from SourceTree on Windows and I don't even care what line endings I have in the remote repository.

[TalentSrc]

Hi All,

Can you please let me know what the solution was and in particular, what the config was in git that solved the issue. I read through the thread and I cannot assimilate what the solution is.

I am stuck with the same issue of sourcetree showing all the files as changed.

Any help, greatly appreciated.