David Deutsch <dd212303 <at> gmail.com> writes: > > 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. > 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. -- 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