On Tue, Dec 18, 2012 at 01:15:30PM +0100, Torsten Bögershausen wrote:
> I could re-produce the problem here:
> git version 18.104.22.168.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
But you can make sure all files are stat-dirty by just resetting the
$ git clone git://boinc.berkeley.edu/boinc.git
$ rm .git/index
$ git reset
which shows the complete list of files with LF/CRLF normalization
> 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,
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html