There is an interesting interaction with the stat matching and autocrlf. $ git init $ git config core.autocrlf true $ echo a >a.txt $ git add a.txt $ unix2dos a.txt $ git diff diff --git a/a.txt b/a.txt At this point, the index records a blob with LF line ending, while the work tree file has the same content with CRLF line ending. And the funny thing is that once you get into this situation it is unfixable short of "git add a.txt". Most notably, "git update-index --refresh" (and the equilvalent auto-refresh that is implicitly run by "git diff" Porcelain) will not update the cached stat information. This is caused partly by the breakage in size_only codepath of diff.c::diff_populate_filespec(). When taking the file contents from the work tree, it just gets stat data and thinks it got the final size, but it should actually convert the blob data into canonical format. diff.c::diffcore_skip_stat_unmatch() is fooled by this and declares that the path is modified. This can be fixed by not returning early even when size_only is asked in the codepath. It will make everything quite a lot more expensive, as there currently is not a cheap way to ask "is this path going to be munged by autocrlf or clean filter", but getting the correct result is more important than getting a quick but wrong result. But that is just a half of the story. (1) It won't make the entry stat clean, as refresh_index() later called from builtin-diff.c to clean up the stat dirtiness works without paying attention to the autocrlf conversion. (2) It won't help lower-level diff-files and internal callers to ce_match_stat() that checks if the path were touched. The "read-tree -m -u" codepath uses it to avoid touching the path with local modifications. The standard way to clear the stat-dirtiness with "git update-index --refresh" still needs to be fixed anyway. I was going to conclude this message by saying "I need to sleep on this to see if I can come up with a clean solution", but it appears I do not have much time left for actually sleeping X-<. - 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