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

[Junio C Hamano <gitster@pobox.com>]

Torsten Bögershausen <tboegi@web.de> writes:

>> Sure, I wasn't saying 1-4 looked wrong at all.  I was wondering why
>> the ones in the middle, especially 7, shouldn't be moved forward
>> together with them.
> The main reason is, that 7 breaks t6038 under Windows.
> (And I discovered that too late :-(
> And as Windows is the platform being most interested in CRLF handling,
> I need to re-do some work.

OK.

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.