CODEWITHSUNDEEP
git
David Deutsch
David Deutsch

Reputation: 19025

Git - Spontaneous "changes" in working dir upon checking out a commit

When I checkout a particular commit in my repo and immediately do a git status, there is a file that shows up as changed. If I look at the SHAs for my working copy and the copy in the index/repo, they are indeed different. The working copy has carriage returns, and while I suspect the copy in the index/repo does not have them, the output from git cat-file on the repo SHA does have them. In fact, if I redirect that output to a file and do a git hash-object of that file, I get back the same SHA as the working copy.

Doing a git checkout on the file changes nothing, i.e. it is still marked as changed in git status. Trying to checkout another commit fails, as my "changes" to the file would be overwritten by the checkout. Doing a git diff on the file returns nothing.

The repo has a .gitattributes file, which starts out with * text=auto !eol. Every file in the repo is explicitly listed in .gitattributes with -text, except the file that has the spontaneous "changes". On my machine, core.autocrlf is false.

This is running on Windows. Git version is 1.9.5.msysgit.1.

Does anyone know what might be going on here? It is almost as if git is adding the CRs to the file at checkout, but not "realizing" that when it comes to deciding if there are local changes.

Thanks for any insight.

Upvotes: 1

Views: 45

Answers (1)

David Deutsch
David Deutsch

Reputation: 19025

OK, so I am pretty sure I have this figured out. Contrary to my belief, the file in the repo did have CRs in it, and was thus exactly equal to my working copy. However, since * text = auto was specified in .gitattributes, the "clean" version git status uses would have its CRs stripped, i.e. upon commit. So, git considers the files different.

An interesting thing to note is that while I was able to reproduce this with a test repository using * text = auto in .gitattributes, I could not reproduce it if I did not have that line, even while setting core.autocrlf to true. The documentation implies the behavior should be the same, but that is obviously not the case.

Upvotes: 2

Related Questions