Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

2 votes
Answer accepted

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:

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:


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.

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
Community showcase
Posted in Sourcetree

[dev team] Sourcetree for Windows 2019 Preview - Dark Theme

Hi folks, While the full post is over on our blog I'd like to share the dark theme we've got planned for 2019 here directly as well to keep the discussion going.  The ...

3,280 views 19 18
Join discussion

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you