Re: BUG: git grep behave oddly with alternatives

From: Diomidis Spinellis <dds@aueb.gr>
Date: Jan 14, 2023, 12:45 UTC
Message-ID: <ab50c16f-dbb0-0661-4d08-fa150d31f88b@aueb.gr>
In-Reply-To: <b2e597aa-044d-e136-43b9-afc84a1e3794@web.de>

On 14-Jan-23 10:31, René Scharfe wrote:

Show 21 quoted lines

> 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