Re: BUG: git grep behave oddly with alternatives

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

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

René