Alexandre Garnier <zigarn@xxxxxxxxx> writes: > echo '* text=auto' > .gitattributes > git add .gitattributes > git commit -q -m "Normalize EOL" > echo -ne 'some content\r\nother \rcontent with CR\r\ncontent\r\nagain With text=auto, the user instructs us to guess, and we expect either LF or CRLF line-terminated files that is *TEXT*. A lone CR in the middle of the line would mean we cannot reliably guess---it may be LF terminated file with CRs sprinkled inside text, some of which happen to be at the end of the line, or it may be CRLF terminated file with CRs sprinkled in. We try to preserve the user input by not munging when we are not sure. You are seeing the designed and intended behaviour. But it would be a bug if the same thing happens when the user explicitly tells us that the file has CRLF line endings, and I suspect we have that bug, which may want to be corrected. I've Cc'ed various people who worked on convert.c around line endings. I recall we saw a few other discussion threads on text=auto and eol settings. Stakeholders may want to have a unified discussion to first list the issues in the current implementation and come up with fixes for them. 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