From: Johannes Sixt <j6t@kdbg.org>
To: "René Scharfe" <l.s.r@web.de>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: js/drop-mingw-test-cmp, was Re: What's cooking in git.git (Dec 2022, #03; Sun, 11)
Date: Sun, 25 Dec 2022 16:44:12 +0100 [thread overview]
Message-ID: <ef79236a-1c47-8775-3acb-aa23b7a300f9@kdbg.org> (raw)
In-Reply-To: <2090204b-52e9-a22f-f0c9-f812d1231863@web.de>
Am 24.12.22 um 14:31 schrieb René Scharfe:
> 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?
Good catch! Looks like I am wrong. In my environment I give the Windows
tools precedence over the MinGW tools. There is a tar.exe in
C:\Windows\System32 that writes CRLF (instead of just LF) that I was
using in my test runs.
> 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.
Yes, indeed, NATIVE_CRLF has nothing to do with the CRLF vs LF behavior
of the toolset. We can ignore it in this discussion. Sorry for bringing
it to the table.
>> 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?
I'm not going to measure it (one full run takes ~2 hours). I trusted
Dscho's argument that this patch brings a much better improvement based
on the one case that is cited in the commit message, but if that was
just an extraordinary outlier, I am not sure anymore...
-- Hannes
next prev parent reply other threads:[~2022-12-25 15:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-11 5:18 What's cooking in git.git (Dec 2022, #03; Sun, 11) Junio C Hamano
2022-12-12 7:50 ` js/drop-mingw-test-cmp, was " Johannes Schindelin
2022-12-12 21:43 ` Junio C Hamano
2022-12-20 22:59 ` Johannes Schindelin
2022-12-21 13:05 ` Junio C Hamano
2022-12-24 8:10 ` Johannes Sixt
2022-12-24 13:31 ` René Scharfe
2022-12-25 14:45 ` Junio C Hamano
2022-12-25 15:44 ` Johannes Sixt [this message]
2022-12-26 19:53 ` René Scharfe
2022-12-27 12:52 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ef79236a-1c47-8775-3acb-aa23b7a300f9@kdbg.org \
--to=j6t@kdbg.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=l.s.r@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).