On 08/09/16 09:35, Jeff King wrote:
> On Thu, Sep 08, 2016 at 04:14:46AM -0400, Jeff King wrote:
>> On Thu, Sep 08, 2016 at 04:10:24AM -0400, Jeff King wrote:
>>> On Thu, Sep 08, 2016 at 09:54:51AM +0200, Johannes Schindelin wrote:
>>>>>  diff.c             |  3 ++-
>>>>>  diffcore-pickaxe.c | 18 ++++++++----------
>>>>>  xdiff-interface.c  | 13 ++++---------
>>>>>  3 files changed, 14 insertions(+), 20 deletions(-)
>>>> I just realized that this should switch the test_expect_failure from 1/3
>>>> to a test_expect_success.
>>> Yep. I wonder if we also would want to test that we correctly find
>>> regexes inside binary files.
>>> E.g., given a mixed binary/text file like:
>>>   printf 'binary\0text' >file &&
>>>   git add file &&
>>>   git commit -m file
>>> then "git log -Stext" will find that file, but "--pickaxe-regex" will
>>> not (using stock git). Ditto for "-Gtext".
>>> Your patch should fix that.
>> Of course if I had actually _looked carefully_ at your patch, I would
>> have seen that your test doesn't just check that we don't segfault, but
>> actually confirms that we find the entry.
>> Sorry for the noise.
> Actually, I take it back again. Your test case doesn't have an embedded
> NUL in it (so we check that git finds it, but aside from the lack of
> segfault, stock git would already find it).

This reminds me ... despite the native cygwin regex library no longer
having the 'regex bug' (ie t0070.5 now passes), I still have NO_REGEX
set on cygwin. This is because, when building with the native library,
we have an "unexpected pass" for t7008.12, which looks like:

test_expect_failure 'git grep .fi a' '
        git grep .fi a
[where the file a is set up earlier by: echo 'binaryQfile' | q_to_nul >a]

commit f96e5673 ("grep: use REG_STARTEND for all matching if available",
22-05-2010) introduced this test and expects ".. NUL characters themselves
are not matched in any way". With the native library on cygwin they are
matched, with the compat/regex they are not. Indeed, if you use the system
'grep' command (rather than 'git grep'), then it will also not match ... :-D

Slightly off topic, but ...

Ramsay Jones

Reply via email to