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

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Sourcetree showing entire-file diffs instead of just the changed lines

I'm looking at Uncommitted changes in my local repo, and every file shows in the diff as deleting all lines and replacing them. This is not accurate. For example, a simple `git diff` shows just the (few) changed lines correctly. This started a couple of days ago and is rendering SourceTree pretty useless. What gives?

Version: 1.6.20.

I did a repair installation, but that didn't fix it.

I did a complete uninstall and reinstall, but that also had no effect.


The line endings did not change. I use the End of the Line Visual Studio extension and very carefully viewed the files before and after.

Additionally, the problem doesn't always occur. Once I made a new commit with the changes I was examining when first writing this post, they looked correct. but when I pressed F5 to refresh (as it was still, incorrectly, showing Uncommitted changes as well as the new branch I made), the diff again is showing the entire file being removed and added again.

Based on the comment about whitespace diff, I did toggle the "Show whitespace" option to "Ignore whitespace" and this showed the diff correctly. However, there I made no whitespace changes in the file. I guarantee this. I used the External Diff option with P4Merge and it shows only the few lines changed as expected. If necessary I will gather screen shots but that will take some time as I'll have to construct some fake files, since I can't share proprietary code.

So it appears that the problem is that Sourcetree is incorrectly seeing some kind of whitespace difference even though there isn't one. But that's unlikely. Thoughts?


The automatic line-ending handling in git and Visual Studio tricked me. Some tools are smart enough to ignore the line ending changes (git is always talking about leaving the files alone on disk, but fixing the line endings during commits), and other tools are not smart enough (or alternately, they are the right and lesser amount of smart, not hiding a problem that is actually there).

I recently had a corruption in my local git repo, so I recloned the remote repo, added the broken repo as a remote, and brought all the interesting branches over into the new local repo. Somewhere in all that, all the LFs in many files were changed to CRLF. Given that all LFs were being changed CRLF during commit anyway, this masked the problem in some situations, but in others tools detected the LF change. Opening the files in Visual Studio showed no change because the files actually have CRLF on disk, but not in the remote repo (but git for diff and working tree purposes ignores these differences).

Apparently some part of the process of re-cloning the repo dealt with the line-ending characters differently than the first time I cloned (perhaps a setting changed in the meantime).

It turned out we were both right (sort of). I didn't make any whitespace changes for this commit, git didn't see any whitespace changes, P4Merge didn't see any whitespace changes (I double-checked it was set to show them), but SourceTree did, and finally what put me on the right track is that gitlab did see the whitespace changes.

Thanks for your patience and your suggestions.


It is possible that a change to SourceTree might be in order, to at least display the diff in a more natural way (such as interleaving the lines and showing whitespace changes, instead of just going for the nuclear option of remove all lines and re-add them).

9 answers

1 accepted

3 votes
Answer accepted
Seth Rising Star Sep 15, 2015

Agreed, and indentation is another possibility. You should check whether SourceTree is configured to show whitespace changes in the diff view (the gear icon on the right).

If that's all true, then it does sounds like some kind of a bug in SourceTree.

Seth Rising Star Sep 16, 2015

Yeah, I can't think of any reason besides whitespace that should cause the described behavior. You should submit a bug report to If you are willing to take the time, also post a link to the bug here as a new answer for posterity.

I was wrong. There were wholesale line-ending changes made without me realizing it due to re-cloning my repository to fix some corrupted files in git. See my updated question.

0 votes
Seth Rising Star Sep 16, 2015

In regards to Update 2, it would certainly be user-friendly if the lines were interleaved, but diff software doesn't typically work that way, so I wouldn't expect ST devs to put the effort into changing it. However, if you want to file a feature request and see where it goes:

0 votes
Seth Rising Star Sep 15, 2015

I don't know of anything besides whitespace issues that would cause the errors you're seeing. P4Merge should also give you the option of showing or ignoring various types of whitespace, I'm not sure what the default is.

0 votes

I'm out of ideas at this point. I believe you about the whitespace , although you might try looking with a hex editor. Other than that, I don't know - but at least you have a workaround.

@Tim Crall @seth.foss

I responded to your comments with an update.

0 votes

Although if it was whitespace, git diff should have shown it as well unless -w was used

0 votes

cool, I didn't know that setting was there. That's probably worth converting to an answer.

0 votes

Probably a problem with line endings. Have you gone back and forth between a PC and a Mac or Unix workstation with your commits?

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events