When viewing staged or unstaged changes via either git extensions or using the git diff commmand I can see that git thinks the whole file has changed. It displays a removal block for the whole file followed by an addition block (or vice versa) thus making it difficult to see exactly what has changed.
When I view the changes in a diff viewer such as winmerge, I can see the exact changes. Suspecting that it may be something to do with line-ending settings in git I decided to change the line ending settings in winmerge by checking the option 'Preserve origin EOL chars' thinking this would emulate the problem I'm seeing in git. However, this makes no difference. Somehow there are line-ending changes that git can see that the diff viewer cannot.
I get a related problem when I perform a git reset --hard. Git sill thinks some files have changed and displays them in the same way as described above but the diff viewer thinks nothing has changed. Annoyingly, performing a git reset --hard does not get rid of the files.
Any ideas?
=== Extra Note ====
It turns out that historically we had not configured the line endings in the repository which meant that the setting core.autocrlf used the default value of 'false' (see https://help.github.com/articles/dealing-with-line-endings/ for further explanation of this setting). A new .gitattributes file had been added with this configuration having a value of 'auto'. As a short term fix we commented out the setting of the text attribute so we reverted back our original settings. However, it's probably best if we adopt the recommended setting of 'auto' which requires a normalisation of the line endings.
