I noticed that if a file subject to a safecrlf warning is added to the index in the same second that it is created, resulting in a "racily clean" index entry, then a subsequent "git add" command prints another safecrlf warning. I reproduced this on the current "next" (499d7c4f91). The procedure: $ git init $ git config core.autocrlf true $ echo foo >file1 && git add file1 && git add file1 warning: LF will be replaced by CRLF in file1. The file will have its original line endings in your working directory. warning: LF will be replaced by CRLF in file1. The file will have its original line endings in your working directory. $ echo bar >file2 && sleep 1 && git add file2 && git add file2 warning: LF will be replaced by CRLF in file2. The file will have its original line endings in your working directory. This came up when I ran the test suite for Braid on Windows (https://github.com/cristibalan/braid/issues/77). The phenomenon actually seems to be more general: touching the file causes the next "git add" to print a safecrlf warning, suggesting that the warning occurs whenever the index entry is dirty. One could argue that a new warning is reasonable after touching the file, but it seems clear that "racy cleanliness" is an implementation detail that shouldn't have user-visible nondeterministic effects. In either case, if "git update-index --refresh" (or "git status") is run before "git add", then "git add" does not print the warning. On the other hand, if line endings in the working tree file are changed, then git shows the file as having an unstaged change, even though the content that would be added to the index after CRLF conversion is identical. So it seems that git remembers the pre-conversion file content and uses it for "git update-index --refresh" and would just need to use it for "git add" as well. Thoughts about the proposed change? Does someone want to work on it or give me a pointer to where to get started? Thanks, Matt
