Junio C Hamano <gitster@xxxxxxxxx> writes: > Torsten Bögershausen <tboegi@xxxxxx> writes: > >> On 29.04.16 23:09, Junio C Hamano wrote: >> >>> Well, didn't I do exactly the above much earlier and discarded it >>> because that breaks the definition of "diff"? Or is this doing >>> something differently? >> >> Yes, and I try to sneak it in anyway ;-) >> >> I spend some time debugging how to get t6038 passed, and need >> some more time. >> >> If 10/10 is a no-go (and it probably should be), >> does it make sense to keep 1/10..4/10 and discard 5..10 for the moment ? > > Earlier patches in the series certainly felt alright. I do not > remember noticing where it went in a strange direction to be honest. Let's step back a bit and make sure we are on the same page. I think this "series" conflates a bit too many things into a single topic. * The comparison between the index and the working tree, i.e. "git diff", should compare result of convert_to_git() with what is in the index, and the world around it should be made consistent with that. Your separate "git blame" fix to add missing knowledge that convert_to_git() would not do s/CRLF/LF/ for a path whose index entry already is contaminated with CR falls into this category and was a very good thing to do. * A convert_to_git() and convert_to_working_tree() pair that do not roundtrip would (by definition) leave contents in the working tree, that, when passed through convert_to_git(), will be different from the index, upon completion of "reset --hard". We _should_ fix it so that "git diff" _reports_ differences. Currently, lstat(2) based optimization hides this in a racy way (when racy Git kicks in to reinspect the index and the working tree file actually matches, it finds out that they do not match), it is a bug that needs to be fixed, not 10/10 where it tries to hide the differences consistently and spreads the bug. I haven't studied 8/10 carefully yet, but it seems to attempt the same. * I think the "text=auto eol=THIS" that did not mean "I do not care to specify which ones are text files. Please detect the file type, and for those automatically detected, please make sure that the contents follwo THIS eol convention." was a bug, and what 07/10 tries to do is a good thing. By the way, lack of the cover letter of this series made it more painful to write a reply like this than necessary. A cover letter for a trivial 3-patch series might be overkill, but for anything with substance that spans more than 4-5 patches, a cover letter to describe the overall direction would really help. Thanks. -- 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