18

Here is my system dialogue:

unrollme-dev-dan:views Dan$ git reset --hard HEAD
HEAD is now at 3f225e9 Fix scan titles
unrollme-dev-dan:views Dan$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   app/signup/finish.html
#   modified:   app/signup/scan.html
#

I have autocrlf set to false:

unrollme-dev-dan:unroll-website Dan$ git config core.autocrlf
unrollme-dev-dan:unroll-website Dan$ 
unrollme-dev-dan:unroll-website Dan$ git config --global core.autocrlf
unrollme-dev-dan:unroll-website Dan$

And I don't have any .gitattributes files messing this up:

unrollme-dev-dan:unroll-website Dan$ find . -name .gitattributes
[ only results are in different directory tree ]

This is caused by a .gitattributes one level up as pointed out in answer below.

When I do an od -c on the files it shows \r\n. I don't know what they "should" be, presumably, they should end in \n and that is why the diff is showing. But what I don't understand is how these files could possibly be modified on checkout even with autocrlf false.

What can cause git modifying a file on checkout besides autocrlf?

djechlin
  • 59,258
  • 35
  • 162
  • 290
  • May be a duplicate of [this question](http://stackoverflow.com/questions/11005688/git-autocrlf-false-git-status-still-shows-modifications), not voting to close until one of these has a correct answer that works for both. – djechlin Mar 28 '13 at 15:45
  • What OS btw? Windows I assume? – Ikke Mar 28 '13 at 16:21
  • @Ikke Mac/Unix. It seems my home Mac dropped extra CRs anyway, I probably have nano config'ed wrong. – djechlin Mar 28 '13 at 16:24
  • Also check `core.safecrlf`. In theory, since `core.eol` and `core.autocrlf` are off, this shouldn't have any effect, but I haven't really played with all possible combinations of the three variables... – twalberg Mar 28 '13 at 18:02

2 Answers2

21

This problem can be caused by gitattributes' text option https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

This problem can be fixed by temporarily editing your .gitattributes file within your project folder.

change * text=auto to #* text=auto make the necessary changes to files line endings and push your commit. You can then enable it again after the change has been made, or alternatively select one of the other options that may better suit your project.

quirkystack
  • 1,387
  • 2
  • 17
  • 42
Cris Favero
  • 632
  • 8
  • 16
  • Of course, if you're working on the same git repo you can notice there in fact *was* a .gitattributes file, just not one I found in my search... – djechlin Mar 28 '13 at 18:08
  • Thanks! My case was slightly different: a .jar file suddenly showing as modified after I added .gitattributes. I added a line in there with: *.jar binary – savedario May 10 '16 at 21:52
4

I didn't have a gitattributes file as is mentioned in the accepted answer, it was a file permissions problem in my case. To see if this is your problem check the changed files' differences with git diff, e.g.:

git diff path/to/file.html

If the only change you see is old mode/new mode, it's likely a permissions problem. You can tell git to ignore file permission changes using:

git config core.filemode false

or

git config --global core.filemode false

(depending on how you use git).

I recently switched from using Cygwin git to git for Windows for performance reasons, plus so that TortoiseGit works properly, this may be the reason permissions were thrown off in my case.

References:

  1. How do I remove files saying "old mode 100755 new mode 100644" from unstaged changes in Git?
Community
  • 1
  • 1
Samuel
  • 8,063
  • 8
  • 45
  • 41