Re: js/drop-mingw-test-cmp, was Re: What's cooking in git.git (Dec 2022, #03; Sun, 11)

[Junio C Hamano <gitster@pobox.com>]

René Scharfe <l.s.r@web.de> 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.