mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Duy Nguyen <>
Cc: "Randall S. Becker" <>,
	Git Mailing List <>
Subject: Re: [Breakage] 2.20.0-rc0 t1404: test_i18ngrep reports 1 instead of 0 on NonStop in one case
Date: Mon, 11 Feb 2019 13:07:15 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Duy Nguyen's message of "Mon, 11 Feb 2019 16:56:33 +0700")

Duy Nguyen <> writes:

> On Mon, Feb 11, 2019 at 2:09 AM Randall S. Becker
> <> wrote:
>> Hi All,
>> I tracked down a breakage in t1404 subtest 52. The line
>> test_i18ngrep "Unable to create $Q.*packed-refs.lock$Q: File exists" err
> The message does not match, does it? Here we grep for "File exists"
> but the message you showed says "File already exists".

Hmph, this is from strerror(), right?

The question is if we should be using grep to match on strerror()
result in the C locale.  Do we really care that the reason of the
failure is due to EEXIST for this particular test?

>> The verbose output, with diagnostics, is:
>> error: 'grep Unable to create '.*packed-refs.lock': File exists err' didn't
>> find a match in:
>> error: Unable to create '/home/git/git/t/trash
>> directory.t1404-update-ref-errors/.git/packed-refs.lock': File already
>> exists.

Otherwise, perhaps we should loosen the grep pattern, not as a part
of "NonStop fix" topic, but as "tests should not depend on having a
canonical spelling of strerror() result even in C locale" topic.

  parent reply	other threads:[~2019-02-11 21:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-10 19:08 [Breakage] 2.20.0-rc0 t1404: test_i18ngrep reports 1 instead of 0 on NonStop in one case Randall S. Becker
2019-02-11  9:56 ` Duy Nguyen
2019-02-11 14:09   ` Randall S. Becker
2019-02-11 21:07   ` Junio C Hamano [this message]
2019-02-11 21:48     ` Randall S. Becker
2019-02-12  0:27     ` Jeff King
2019-02-12  0:32       ` Junio C Hamano
2019-02-12  0:35         ` Jeff King
2019-02-14 20:16       ` Re* " Junio C Hamano
2019-02-14 20:32         ` Randall S. Becker
2019-02-14 21:15           ` Junio C Hamano
2019-02-15  6:08         ` Martin Ågren
2019-02-15 17:51           ` 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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* 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

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