Re: BUG: git grep behave oddly with alternatives

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jan 12, 2023, 17:52 UTC
Message-ID: <230112.86mt6nzlk5.gmgdl@evledraar.gmail.com>
In-Reply-To: <4165031d-e7f1-0477-2245-6a8e312de522@web.de>

On Thu, Jan 12 2023, René Scharfe wrote:

Show 16 quoted lines

> Am 11.01.23 um 19:56 schrieb Jeff King:
>> On Sun, Jan 08, 2023 at 01:42:04AM +0100, René Scharfe wrote:
> [...]
>>> Which begs the question: Isn't that a problem for the platforms that
>>> still have to use NO_REGEX?  Shouldn't we fix compat/regex?
>>
>> I'm not sure. I always assumed our fallback was similar-ish to what was
>> in glibc and was thus pretty featureful, but that may not be true (it
>> actually comes from gawk). It looks like we just didn't pull over the
>> multi-byte parts in a997bf423d (compat/regex: get the gawk regex engine
>> to compile within git, 2010-08-17).
>
> GAWK removed NO_MBSUPPORT, NO_MBSUPPORT and mbsupport.h in the meantime.
> I guess that means they support multi-byte characters everywhere now.
>
> René

Note that GAWK doesn't really have its own regex engine, their is mostly glibc.git's, which they've ported over to their codebase with some difficulty over the years (it not being in gnulib, like most such shared GNU libraries).

Ours is then an old copy of gawk.git's, which I attempted to update a few years back, but that patch series ran into some issues I can't remember, so we still have that very old version.