When I checkout a particular commit in my repo and immediately do a git status, there is a file that show 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 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 as -text, *except* the file that has the spontaneous "changes". The file's suffix is .cs, which I thought was automatically considered text anyway. 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html