Torsten Bögershausen <tboegi@xxxxxx> 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. -- 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