From: Adam Dinwoodie <adam@dinwoodie.org>
To: git@vger.kernel.org
Cc: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>,
"Jonathan Nieder" <jrnieder@gmail.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Binary grep t7008 known breakage vanished on Cygwin
Date: Mon, 18 Apr 2016 16:21:49 +0100 [thread overview]
Message-ID: <20160418152149.GD2345@dinwoodie.org> (raw)
t7008.12 is marked as an expected failure, but building Git on Cygwin
including a `make configure && ./configure` step has the test
unexpectedly passing. Building without the configure step has the test
failing as expected.
This appears to be behaviour specific to Cygwin; at least I get that
test failing on my CentOS box regardless of whether I perform the
configure step.
The "problem" here is `git grep` is matching a null byte with a "."; the
test implies that ought to work in theory but hasn't worked in practice
since the test was added in v1.7.1-101-gf96e567. The commit message
there asserts "NUL characters themselves are not matched in any way,
though", which is evidently not the case on Cygwin, provided the
`configure` script is run.
I'm not sufficiently familiar with the standards and library interfaces
here to have any idea what the "correct" regex behaviour in this
circumstance is.
I'm not sure what the correct thing to do in the face of such an
unexpected test pass; it looks as though Cygwin Git's `grep` is going to
behave in a subtly different way to Git on other platforms as a result
of this, which is probably not ideal, but I don't know if there's
anything that "ought" to be done to either ensure consistent behaviour
across platforms, or to stop marking the test as an expected failure on
platforms where it passes.
Adam
next reply other threads:[~2016-04-18 15:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-18 15:21 Adam Dinwoodie [this message]
2016-04-18 17:08 ` Binary grep t7008 known breakage vanished on Cygwin Ramsay Jones
2016-04-19 8:42 ` Adam Dinwoodie
2016-04-19 18:52 ` Ramsay Jones
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160418152149.GD2345@dinwoodie.org \
--to=adam@dinwoodie.org \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=rene.scharfe@lsrfire.ath.cx \
/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.
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 NNTP newsgroup(s).