Can someone explain to me what difference git diff is seeing here?

Question

I am using git on Windows 7 via msysgit. An issue that has been causing me a lot of grief lately is that as soon as I switch to certain branches, git thinks that some files have been changed and then I can do nothing to make it stop thinking those files have changed.

The steps to reproduce in my case (which might not be relevant to everybody) are as follows:

1. Checkout the master branch.
2. Checkout the pristine-3.7 branch.
3. Checkout the pristine-3.8 branch.
4. Checkout the pristine-3.9 branch.

At this point, git starts to assume that files have changed.

For example, here's a screenshot of a git diff output.

Here's the diff output for the same file using Beyond Compare in Hex mode.

And finally, the git status output!

What's going on?

Update to the question:

A possible solution is to commit the changes locally and then to delete that commit without putting the changes in the commit back into the working state. How is that done?

Answer 1

I have this problem constantly - the only thing that works is:

git rm --cached -r . > /dev/null # redirect if output is huge
git reset --hard

but make sure you have no changes you want to keep

See git line endings - can't stash, reset and now can't rebase over spurious line endings commit

Someone must make a example repo that exhibits this behavior and post it to the git tracker - this is a bug (in the sense that git reset --hard and co should work immediately)

EDIT: make sure you have read the required reading and set up a .gitattributes file

Answer 2

Sounds like autocrlf issue. In addition, you might have smudge and clean filters enabled with a custom implementation that is causing issues.

I'd suggest doing

git diff --raw master pristine-3.9 -- packages/fop-10/lib
git diff --raw pristine-3.7 pristine-3.9 -- packages/fop-10/lib

and inspecting the results. Rest assured that git does save the binary contents and the saved binary contents matches the SHA-1 of the tip of the branch. However, the binary contents may not match the working directory binary contents if you use some features (e.g. autocrlf or smudge). The autocrlf is more prone to cause issues for Windows users because Windows users still suffer from a historical Microsoft decision to use two byte code for a single line feed instead of a single byte code used in historical UNIX compatible systems and Machintosh OS.