Am 24.12.22 um 09:10 schrieb Johannes Sixt: > 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@xxxxxx/
