git memory error? cannot checkout/reset/undo a change

After a pull, git status tells me that I have changed a 16Mb xml file.

I have 开发者_StackOverflownot touched this file; but its possible that EOL issues cause git's confusion (though I think not as I have autocrlf = input ).

Yet I write because I cannot get rid of this thing.

I have tried each of the following :

1. git reset --hard HEAD
2. git checkout -- derived/workflow/xml/definitions.xml
3. git stash save

After each of these, git status tells me :

# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   derived/workflow/xml/definitions.xml

This is a problem because I can't "stash pop" afterward, (even immediately after #3 above, after doing a 'git stash save')

Environment

• Windows XP
• Cygwin Git 1.7.1

Some questions

• Is git failing silently due to this large file size? (Earlier I briefly saw git fail on a memory issue)
• How do I work around this problem?

Thanks

In this case, the problem stemmed from my "autocrlf" setting to "input".

For better or worse, our build process generated xml files with "CRLF" line endings.

"git status" must work in conjunction with "autocrlf". Though I had not touched or edited the file, "git status" must say "when you commit this file, git will have to modify it, so I will report it right-now as modified".

The "solution" was to turn off autocrlf.

With no autocrlf, git status returned "the right thing"

I ran into a similar problem which was due to the case of filenames. In the repository, there was a file called file.txt and another called File.txt (or other such names that differed only by case). Git doesn't expect this, and when checking out the repo on a non-case-sensitive filesystem (Mac OS X in my case), I had this same sort of problem.

My eventual solution was to entirely exclude the directory containing the file from that checkout. In my situation I didn't need that directory in that situation, which was lucky.