> 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? tb/core-eol-fix would be my suggestion, or core-eol-t0027-fix. > 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. > That makes sense and will remove the shakiness, right ? We only need to pay extra attention when there is an external clean/smudge filter defined - otherwise we should be able to skip it - after 10/10. -- 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