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

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)?

2 answers

1 accepted

This widget could not be displayed.

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. 

yep, line endings for sure

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

Thanks everyone! I will investigate the line ending issue.

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.

 

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.

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.
This widget could not be displayed.

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.

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Published May 30, 2018 in Sourcetree

Tip from the team: configuring Git or Mercurial in Sourcetree

Supported Platforms macOS Windows To make using Sourcetree as simple yet powerful as possible we embed (bundle) dependencies such as Git, Git LFS, and Mercurial. We strive to keep these...

709 views 1 3
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you