An interaction with ce_match_stat_basic() and autocrlf

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-<.