{"thread":{"id":"39514","subject":"Spontaneous \"changes\" upon checking out a commit","startedAt":"2015-06-03T11:57:12Z","lastAt":"2015-06-05T16:59:00Z","messageCount":2,"participants":["David Deutsch"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"262861","messageId":"CAE-vyzgSqqidjsD7XByLY+T4G78yUtO-q3G63au4uNPO=1_tcQ@mail.gmail.com","threadId":"39514","inReplyTo":null,"subject":"Spontaneous \"changes\" upon checking out a commit","fromName":"David Deutsch","fromEmail":"dd212303@gmail.com","sentAt":"2015-06-03T11:57:12Z","receivedAt":"2015-06-03T11:57:12Z","isPatch":false,"sender":{"key":"dd212303@gmail.com","avatar":null},"body":"When I checkout a particular commit in my repo and immediately do a\ngit status, there is a file that show up as changed. If I look at the\nSHAs for my working copy and the copy in the index/repo, they are\nindeed different. The working copy has carriage returns, and while I\n*suspect* the copy in the index/repo does not have them, the output\nfrom git cat-file on the repo SHA does have them. In fact, if I\nredirect that output to a file and do a git hash-object of that file,\nI get back the the same SHA as the working copy.\n\nDoing a git checkout on the file changes nothing, i.e. it is still\nmarked as changed in git status. Trying to checkout another commit\nfails, as my \"changes\" to the file would be overwritten by the\ncheckout. Doing a git diff on the file returns nothing.\n\nThe repo has a .gitattributes file, which starts out with \"* text=auto\n!eol\". Every file in the repo is explicitly listed in .gitattributes\nas -text, *except* the file that has the spontaneous \"changes\". The\nfile's suffix is .cs, which I thought was automatically considered\ntext anyway. On my machine, core.autocrlf is false.\n\nThis is running on Windows. Git version is 1.9.5.msysgit.1.\n\nDoes anyone know what might be going on here? It is almost as if git\nis adding the CRs to the file at checkout, but not \"realizing\" that\nwhen it comes to deciding if there are local changes.\n\n\nThanks for any insight.\n"},{"id":"263039","messageId":"loom.20150605T185726-583@post.gmane.org","threadId":"39514","inReplyTo":"CAE-vyzgSqqidjsD7XByLY+T4G78yUtO-q3G63au4uNPO=1_tcQ@mail.gmail.com","subject":"Re: Spontaneous \"changes\" upon checking out a commit","fromName":"David Deutsch","fromEmail":"dd212303@gmail.com","sentAt":"2015-06-05T16:59:00Z","receivedAt":"2015-06-05T16:59:00Z","isPatch":false,"sender":{"key":"dd212303@gmail.com","avatar":null},"body":"David Deutsch <dd212303 <at> gmail.com> writes:\n\n> \n> When I checkout a particular commit in my repo and immediately do a\n> git status, there is a file that show up as changed. If I look at the\n> SHAs for my working copy and the copy in the index/repo, they are\n> indeed different. The working copy has carriage returns, and while I\n> *suspect* the copy in the index/repo does not have them, the output\n> from git cat-file on the repo SHA does have them. In fact, if I\n> redirect that output to a file and do a git hash-object of that file,\n> I get back the the same SHA as the working copy.\n> \n> Doing a git checkout on the file changes nothing, i.e. it is still\n> marked as changed in git status. Trying to checkout another commit\n> fails, as my \"changes\" to the file would be overwritten by the\n> checkout. Doing a git diff on the file returns nothing.\n> \n> The repo has a .gitattributes file, which starts out with \"* text=auto\n> !eol\". Every file in the repo is explicitly listed in .gitattributes\n> as -text, *except* the file that has the spontaneous \"changes\". The\n> file's suffix is .cs, which I thought was automatically considered\n> text anyway. On my machine, core.autocrlf is false.\n> \n> This is running on Windows. Git version is 1.9.5.msysgit.1.\n> \n> Does anyone know what might be going on here? It is almost as if git\n> is adding the CRs to the file at checkout, but not \"realizing\" that\n> when it comes to deciding if there are local changes.\n> \n> Thanks for any insight.\n> \n\nOK, so I am pretty sure I have this figured out. Contrary to my belief, \nthe file in the repo did have CRs in it, and was thus exactly equal to \nmy working copy. However, since \"* text = auto\" was specified in \n.gitattributes, the \"clean\" version git status uses would have its CRs \nstripped, i.e. upon commit. So, git considers the files different. \n\nAn interesting thing to note is that while I was able to reproduce this \nwith a test repository using * text = auto in .gitattributes, I could \nnot reproduce it if I did not have that line, even while setting \ncore.autocrlf to true. The documentation implies the behavior should be \nthe same, but that is obviously not the case.\n"}]}