Pt/native crlf (updated test) #87
Conversation
The previous patch correctly points out that the NATIVE_CRLF setting is incorrectly set on Mingw git. However, the Makefile variable is not propagated to the C preprocessor and results in no change. This patch pushes the definition to the C code and adds a test to validate that when core.eol as native is crlf, we actually normalize text files to this line ending convention when core.autocrlf is false. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
|
MSysGit - the development behind Git for Windows » git #115 SUCCESS |
|
"! has_cr" is used in this test suite to assert that the lines do not end in CR and, therefore, must end in LF (preceded by a CR). I agree that it is counter-intuitive, but I just matched the style of the tests above. To answer your questions, CRLF endings are applied to fileunix, and the CRs are not stripped from filedos. It is just asserted in a very odd way. |
|
Oh, that is indeed a bummer. We should fix has_cr to succeed if it finds carriage returns. |
|
Actually, I tested this on Linux, and I fear that has_cr does succeed if I put carriage returns through it: $ has_cr() { tr '\015' Q | grep Q >/dev/null; }
$ printf '\r\n' | has_cr && echo yep
yep
$ printf '\n' | has_cr && echo yep |
|
I do realize that above definition lacks a |
|
I'll look into making the test better. |
|
Doh, I just realized I was investigating the wrong failures. I assumed that |
A minor patch to the previous pull request. This version updates the eol=native test to assert that the files use crlf after the conversion.