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

[Erik Eckhardt]

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.

UPDATE

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?

UPDATE 2

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

[Seth · Accepted solution]

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

[Tim Crall]

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

[Seth]

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

[Erik Eckhardt]

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.

[Seth]

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: jira.atlassian.com

[Seth]

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.

[Tim Crall]

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.

[Erik Eckhardt]

@Tim Crall @seth.foss

[Erik Eckhardt]

I responded to your comments with an update.

[Tim Crall]

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

[Tim Crall]

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

[Tim Crall]

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