From: Diomidis Spinellis Date: Sat, 14 Jan 2023 12:45:54 GMT Subject: Re: BUG: git grep behave oddly with alternatives Message-ID: In-Reply-To: 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 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