Re: BUG: git grep behave oddly with alternatives

[Diomidis Spinellis <dds@aueb.gr>]

On 14-Jan-23 10:31, René Scharfe wrote:
> 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:
>>>> 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:

Indeed, I removed the alternation handling functionality by accident.  I 
was not aware of the BRE-handling difference between the GNU and the 
macOS native regex library.  I think having git-grep behave the same as 
grep(1) on each platform is consistent with the principle of least 
astonishment (POLA).  This would mean that on macOS plain git-grep 
should use enhanced basic REs as proposed in René's patch.

Diomidis