Re: [PATCH v8 10/10] ce_compare_data() did not respect conversion

> Let's separate 01-04/10 into a different topic and give it its own
> name; tb/convert-eol-autocrlf was the name I picked primarily for
> 07/10 but 01-04/10 are not about that fix.  Both 02 and 04 are about
> autocrlf (the former is "core.eol is irrelevant when core.autocrlf
> is there", the latter is "fix core.autocrlf used in conjunction with
> ident conversion"), so how about tb/autocrlf-fix or something?

> And then we can merge that to 'next' and to 'master' while we find
> solution to 07/10 which is really the more important bit.
>
> As to (the inverse of) 10/10, I am starting to suspect that the
> correct solution (which may not be the "right" one, though) would
> involve teaching write_entry() that not everything it writes out can
> be marked up-to-date in the index.  A naive implemention would be to
> pass what it writes out to the filesystem through convert_to_git()
> and see if the result matches the blob in the index, and if it does
> not match, make sure ce_mark_uptodate() is not called, perhaps by
> not calling fill_stat_cache_info(), or manually dropping CE_UPTODATE
> bit at the end of the function.
>
> A naive implementation however may turn out to be way too expensive
> to use as-is, I am afraid.  Possible ways to speed up would be to
> skip this "refrain from marking up-to-date" hackery when conversion
> is known to be well behaved.  For example, with the EOL handling
> updated with your series, we may be able to say that the stock
> to-git and to-working-tree pair is guaranteed to roundtrip even with
> EOL conversion, ident conversion as long as there is no end-user
> defined clean/smudge filters.  With such an optimization, the result
> might perform with acceptable performance penalty in common cases.
>