Re: BUG: git grep behave oddly with alternatives

["René Scharfe" <l.s.r@web.de>]

Am 14.01.23 um 07:44 schrieb René Scharfe:
> Am 13.01.23 um 18:19 schrieb Junio C Hamano:
>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>
>>> On Thu, Jan 12 2023, Jeff King wrote:
>>>
>>>> So it does seem like all bets are off for what people can and should
>>>> expect here. Which isn't to say we should make things worse. I mostly
>>>> wondered if REG_ENHANCED might take us closer to what glibc was doing by
>>>> default, but it doesn't seem like it.
>>
>> I thought that René's "Use enhanced only when doing BRE" was fairly
>> focused, but I am very tempted to accept ...
>>
>>> There's a couple of ways out of this that I don't see in this thread:
>>>
>>> - Declare it not a problem: We have -G, -E and -P to map to BRE, ERE and
>>>   PCRE. One view is to say the first two must match POSIX, another is
>>>   tha whatever the platform thinks they should do is how they should
>>>   act.
>>
>> ... this view.  The story "BRE and ERE work via what system
>> libraries provide, and 'git grep' matches what system grep' does" is
>> an easy to understand view.
>
> That was my stance in my first reply as well.  But 3632cfc248 (Use
> compatibility regex library for OSX/Darwin, 2008-09-07) explicitly
> added alternation support for BREs on macOS, and 1819ad327b (grep: fix
> multibyte regex handling under macOS, 2022-08-26) removed it seemingly
> by accident.  And grep(1) does support them on macOS 13.1:
>
>    $ uname -rs
>    Darwin 22.2.0
>    $ which grep
>    /usr/bin/grep
>    $ grep --version
>    grep (BSD grep, GNU compatible) 2.6.0-FreeBSD
>    $ grep '\(REG_STARTEND\|NeededForASAN\)' Makefile
>    # Define NO_REGEX if your C library lacks regex support with REG_STARTEND
>    NO_REGEX = NeededForASAN

And I neglected to copy the author of 1819ad327b until now. :-|

@Diomidis: Here's a link to the start of this thread:
https://lore.kernel.org/git/f82ae28a-fb56-8d1f-96c8-550b61439d3a@enterprisedb.com/

René