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

From: René Scharfe <l.s.r@web.de>
Date: Dec 24, 2022, 13:31 UTC
Message-ID: <2090204b-52e9-a22f-f0c9-f812d1231863@web.de>
In-Reply-To: <3c55ac67-5090-b7af-a212-2996bad66fb2@kdbg.org>

Am 24.12.22 um 09:10 schrieb Johannes Sixt:

Show 9 quoted lines

> Am 21.12.22 um 14:05 schrieb Junio C Hamano:
>> I know we have been operating under such a test environment, but
>> after seeing the exchange between Réne and J6t, I was hoping that we
>> do not have to keep being sloppy.
>
> 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:

   $ uname -rs
   MINGW64_NT-10.0-22621 3.3.6-341.x86_64

   $ git archive HEAD Makefile | tar tf - | hexdump.exe -C
   00000000  4d 61 6b 65 66 69 6c 65  0a                       |Makefile.|
   00000009

Is there some configuration option that I need to set?

> On top of that, there are prerequisites SED_STRIPS_CR,
> GREP_STRIPS_CR and perhaps NATIVE_CRLF that should be reconsidered.

Ah, they are currently set based on the output of "uname -s". Setting them based on the actual behavior of the commands would allow the test suite to automatically adapt to them being replaced by CR-preserving variants. With the current Git for Windows SDK the two prerequisites would still be set, though, so tests would behave the same, right?

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.

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

René

[1] https://lore.kernel.org/git/31d3bf6c-c0a2-d2d5-c6e2-b185fde99170@web.de/