René Scharfe <l.s.r@xxxxxx> writes: >> Things did not turn out to be as simple. After ripping out all >> special-casing of GIT_TEST_CMP from a MinGW build, I notice at least one >> case that needs special treatment (it's `tar tf` that writes CRLF >> output). > > That would affect t6132 and perhaps t9502, right? > > How can I reproduce it? I get only LF: > ... > NATIVE_CRLF seems intended to track the macro of the same name, so it > probably makes sense to mirror config.mak.uname, but a test helper (or > "git version --build-options" line) that returns the actual value would > probably be more robust. I take the above as an indication that it is not yet clear if we can use the same GIT_TEST_CMP as others on MinGW. And ... >> For the time being, I suggest to take Dscho's patch. > > The patch is intended to make comparisons faster. That works for big > files, but the test suite compares small ones. The total duration of > a test suite run is about one minute longer with the patch than without > it for me [1]. I retried with 7c2ef319c5 (The first batch for 2.40, > 2022-12-19), and that's still the case. Do you get different numbers? ... this indeed is a valid concern. With or without the patch, platform tools on MinGW that are muddy about CRLF vs LF are taken care of with the special cased GIT_TEST_CMP either way.
