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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 25, 2022, 14:45 UTC
Message-ID: <xmqq3593o82g.fsf@gitster.g>
In-Reply-To: <2090204b-52e9-a22f-f0c9-f812d1231863@web.de>

René Scharfe <l.s.r@web.de> writes:

Show 13 quoted lines

>> 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 ...

Show 7 quoted lines

>> 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.