From: "René Scharfe" <l.s.r@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Sixt <j6t@kdbg.org>,
Philippe Blain <levraiphilippeblain@gmail.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 2/1] t3920: support CR-eating grep
Date: Mon, 5 Dec 2022 11:43:28 +0100 [thread overview]
Message-ID: <26ed832d-fb97-c0ef-3848-f58ea574a23f@web.de> (raw)
In-Reply-To: <xmqqwn76p55v.fsf@gitster.g>
Am 05.12.22 um 10:32 schrieb Junio C Hamano:
> René Scharfe <l.s.r@web.de> writes:
>
>> Depends on the meaning of "fixed". If it stops removing CRs then this
>> line is unaffected -- .crlf-orig-$branch.txt contains no CRs.
>
> OK, that "fix" was what I was worried about and if there is no
> problem with the input we use, that is good ;-)
>
>> If it
>> starts adding CRs then we'd have a problem with all grep invocations,
>> which was addressed by 4d715ac05c (Windows: a test_cmp that is agnostic
>> to random LF <> CRLF conversions, 2013-10-26).
>
> Yeah, but I thought that the unspoken motivation behind recent
> changes are so that we do not have to rely on "the differences
> between CRLF and LF do not matter" version of test_cmp?
The patch currently enables the removal of mingw_test_cmp; its commit
message mentions it in passing ("[...] especially since this is the only
test that needs it."). If grep (or bash) would be "fixed" to add CRs
then we'd have to deal with that damage e.g. by keeping mingw_test_cmp.
René
next prev parent reply other threads:[~2022-12-05 10:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-21 17:58 [PATCH] t3920: don't ignore errors of more than one command with `|| true` Johannes Sixt
2022-11-21 22:56 ` René Scharfe
2022-11-22 0:53 ` Junio C Hamano
2022-11-22 18:28 ` Philippe Blain
2022-11-22 22:24 ` Ævar Arnfjörð Bjarmason
2022-11-22 22:37 ` Johannes Sixt
2022-11-22 22:57 ` Ævar Arnfjörð Bjarmason
2022-11-23 0:55 ` Junio C Hamano
2022-12-02 16:51 ` [PATCH 2/1] t3920: support CR-eating grep René Scharfe
2022-12-02 23:14 ` Philippe Blain
2022-12-03 7:09 ` René Scharfe
2022-12-02 23:32 ` Eric Sunshine
2022-12-03 7:12 ` René Scharfe
2022-12-05 1:08 ` Junio C Hamano
2022-12-05 8:28 ` René Scharfe
2022-12-05 9:32 ` Junio C Hamano
2022-12-05 10:43 ` René Scharfe [this message]
2022-12-02 16:51 ` [PATCH 3/1] t3920: simplify redirection of loop output René Scharfe
2022-12-02 16:51 ` [PATCH 4/1] t3920: replace two cats with a tee René Scharfe
2022-12-03 5:09 ` Eric Sunshine
2022-12-03 8:43 ` René Scharfe
2022-12-03 12:53 ` Ævar Arnfjörð Bjarmason
2022-12-03 17:22 ` René Scharfe
2022-12-04 9:34 ` Ævar Arnfjörð Bjarmason
2022-12-04 16:39 ` Eric Sunshine
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=26ed832d-fb97-c0ef-3848-f58ea574a23f@web.de \
--to=l.s.r@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=levraiphilippeblain@gmail.com \
/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).