title: Git - Spontaneous "changes" in working dir upon checking out a commit
body: <p>When I checkout a particular commit in my repo and immediately do a
  <code>git status</code>, 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
  <em>suspect</em> the copy in the index/repo does not have them, the output
  from <code>git cat-file</code> on the repo SHA does have them. In fact, if I
  redirect that output to a file and do a <code>git hash-object</code> of that file,
  I get back the same SHA as the working copy.</p>
  
  <p>Doing a <code>git checkout</code> on the file changes nothing, i.e. it is still
  marked as changed in <code>git status</code>. Trying to checkout another commit
  fails, as my "changes" to the file would be overwritten by the
  checkout. Doing a <code>git diff</code> on the file returns nothing.</p>
  
  <p>The repo has a <code>.gitattributes</code> file, which starts out with <code>* text=auto
  !eol</code>. Every file in the repo is explicitly listed in <code>.gitattributes</code>
  with <code>-text</code>, <em>except</em> the file that has the spontaneous "changes". On my machine, core.autocrlf is false.</p>
  
  <p>This is running on Windows. Git version is 1.9.5.msysgit.1.</p>
  
  <p>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.</p>
  
  <p>Thanks for any insight.</p>