Re: BUG: git grep behave oddly with alternatives

From: Jeff King <peff@peff.net>
Date: Jan 12, 2023, 21:54 UTC
Message-ID: <Y8CBrtmL45tA/N8z@coredump.intra.peff.net>
In-Reply-To: <4165031d-e7f1-0477-2245-6a8e312de522@web.de>

On Thu, Jan 12, 2023 at 06:13:13PM +0100, René Scharfe wrote:

Show 16 quoted lines

> > I'm not quite sure what you mean here by "non-greedy repetitions".
> > Something like:
> >
> >   # prefer "foo bar" to "foo bar bar"; only matters for colorizing or
> >   # --only-matching
> >   git grep -E 'foo.*?bar'
> >
> > ? If so, then yeah, that changes the meaning of a bare "?" and people
> > might be surprised by it.
> 
> Right.  To be fair, question mark is a special character and you'd
> probably need to quote it anyway if you want to match a literal
> question mark.  Otherwise I get:
> 
>    $ git grep -E 'foo.*?bar'
>    fatal: command line, 'foo.*?bar': repetition-operator operand invalid

This is on macOS, I assume? With glibc it seems to be quietly ignored:

  $ git grep -E -o 'foo.*?ba' .clang-format
  .clang-format:foo, bar, ba

So it is not treated literally (as it would be without -E). But nor does it make the match non-greedy (otherwise it would have output "foo, ba", as "git grep -P" does).

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.

-Peff