2

I faced problem, that I can't discard changes to the file. In diff it showed that all lines was deleted and new pasted. But content of the file similar to the initial commit in branch. Intellij IDEA shows that there are no diff with repository.

I am new one to GIT, so please be patient)

Constantine
  • 1,802
  • 3
  • 23
  • 37
  • If you run `git checkout ` then check `git diff` again, is the result the same? Also, when you look at the diff, does the contents look the same (maybe the line endings or encoding has changed)? – piojo Nov 12 '14 at 05:35
  • Diff shows that all original lines was removed, and replaced with new(they have identical contents). Line endings also same. – Constantine Nov 12 '14 at 05:41
  • Git doesn't quite work that way. It mostly doesn't know about files, it only cares about file contents. – piojo Nov 12 '14 at 05:53
  • So you discarded the file but `git diff` is still showing it as the same? Are you on a windows system? If the "filemode" setting is true, Git may think the file has changed because it has become executable, due to being checked out on a windows system. – piojo Nov 12 '14 at 05:55
  • Yeap, diff shows same after discard. And yes, I am on Windows. Setting "filemode" to false - doesn't help. – Constantine Nov 12 '14 at 06:01
  • I would still try setting autocrlf=false. You said the line endings are the same, and that could be true, but I wonder whether Git wants to change them and check them in as changed? But that's a shot in the dark. I can't really think of anything. – piojo Nov 14 '14 at 10:06

1 Answers1

2

My best guess as to what is happening is that you are on a Windows machine, and that somewhere in your .gitattributes file you have a directive that tells git to perform line ending normalizations (via * text=auto or something similar). If this is indeed the case, then when you checkout a file its LFs are converted to CRLFs, and when you commit a file its CRLFs are converted to LFs.

If this is indeed the case, then what is most likely happening is that the repository version of the files in question somehow have CRLFs in them. When you check them out, the working copies would of course also have those CRLFs. Now here's the rub: when doing a git status, git diff, etc. git compares what is in the repo/index not to what is actually in your working directory, but to what would be committed after line ending normalization is done, i.e. with the CRLFs replaced by LFs. In this case, git sees that what is in the index/repo has CRLFs, and what you would commit only has LFs, and thus there is a difference.

To see if this is the case, run the following commands:

git hash-object path/to/filename
git hash-object --no-filter path/to/filename
git ls-files -s path/to/filename

The first command will show you the hash of what would be committed. The second command shows you the hash of what is actually in your working directory. The third command shows you the hash of what is in the index. If the first and second hashes are different, and the second and third hashes are the same, you are almost definitely in the situation I have described.

So the question is, how to get out of it? One simple way is to simply add/commit the "changes". This will have the effect of putting LFs in the repository copy, solving the problem going forward. If everyone using the repository is on Windows, however, there is really no need for the line normalizations anyway. You can disable them by putting * -text in your .gitattributes file (and removing any lines below it that sets the type of a file to text). That's the option I chose when I ran into this problem, as I'm not a fan of my version control system changing the contents of my files.

David Deutsch
  • 17,443
  • 4
  • 47
  • 54