On Tue, Dec 18, 2012 at 01:15:30PM +0100, Torsten Bögershausen wrote: > I could re-produce the problem here: > git version 1.8.0.197.g5a90748 > Mac OS X (that what I had at hands fastest) I could reproduce it, too, on Linux. The reason it does not always happen is that git will not re-examine the file content unless the timestamp on the file is older than what's in the index. So it is a race condition for git to see whether the file is stat-dirty. But you can make sure all files are stat-dirty by just resetting the index: $ git clone git://boinc.berkeley.edu/boinc.git $ rm .git/index $ git reset which shows the complete list of files with LF/CRLF normalization issues. > So my conclusion is: > The file has CRLF in the repo, but should have LF. > This is not a good thing, and the files need to be normalized. Yes, exactly. The project has told git via .gitattributes that certain files should have particular line endings in the repository, but that is not the case with the current versions. Doing: $ git commit -a -m 'normalize line endings according to gitattributes' on top of the commands above would fix it (for that commit and onwards, anyway). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html