git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "René Scharfe" <l.s.r@web.de>
Cc: "Marco Nenciarini" <marco.nenciarini@enterprisedb.com>,
	git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: BUG: git grep behave oddly with alternatives
Date: Fri, 6 Jan 2023 04:09:41 -0500	[thread overview]
Message-ID: <Y7flVcALZQgz0VPl@coredump.intra.peff.net> (raw)
In-Reply-To: <e5165840-331c-e9b6-b45f-62abab860d79@web.de>

On Wed, Jan 04, 2023 at 05:36:21PM +0100, René Scharfe wrote:

> > I didn't test, but just from looking at the patch I'd expect this to
> > affect other parts of Git besides git-grep. E.g., "git log --grep".
> > Which raises two questions:
> >
> >  - would a more generalized name be better? USE_REG_ENHANCED or
> >    something? That might be _too_ general, but see below.
> >
> >  - should this cover other cases? Grepping for "regcomp", would people
> >    want this to behave consistently for "git config --get-regexp", or
> >    diff funcnames, and so on?
> >
> > If so, then I could envision a USE_REG_ENHANCED which just wraps the
> > system regcomp and adds the REG_ENHANCED flag when REG_EXTENDED is not
> > set?
> 
> Good point.  I don't know what people want, though.  re_format(7) on
> macOS/BSD and regex(7) on Linux call basic REs "obsolete" and extended
> REs "modern", so they seem to push people away from the old kind,
> enhanced or not.

Oh, good point. I was just grepping for regcomp(), but of course any
case which is already passing REG_EXTENDED would not be affected anyway.
And most places are already using that. E.g., the config code always
does so, and it looks like pickaxe "-G" does so.

For diffs, we have diff.*.xfuncname, which uses EREs. We do still
support regular "funcname" for backwards compatibility, but we only
document the extended version. Ironically, that option was introduced
because BREs did not portably support things like alternation, even with
the "enhanced" syntax. ;) See 45d9414fa5 (diff.*.xfuncname which uses
"extended" regex's for hunk header selection, 2008-09-18).

So I think we are embracing the "everyone should use EREs" mentality
already. The only spots I see that use BREs are:

  - grep.c, which handles "git grep" and "git log --grep"

  - line-range.c, presumably for "-L" function matching

  - deprecated non-ERE funcname patterns

Your patch is handling the first, which is by the far most important. I
would be OK leaving the others as-is, but I also wouldn't mind a patch
that works at the regcomp() level to make things automatically
consistent.

-Peff

  reply	other threads:[~2023-01-06  9:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-03  9:53 BUG: git grep behave oddly with alternatives Marco Nenciarini
2023-01-03 16:29 ` René Scharfe
2023-01-03 18:13   ` Marco Nenciarini
2023-01-03 20:52     ` René Scharfe
2023-01-04  6:13       ` Junio C Hamano
2023-01-04  7:46       ` Jeff King
2023-01-04 16:36         ` René Scharfe
2023-01-06  9:09           ` Jeff King [this message]
2023-01-08  0:42             ` René Scharfe
2023-01-08  1:27               ` Junio C Hamano
2023-01-11 18:56               ` Jeff King
2023-01-12 17:13                 ` René Scharfe
2023-01-12 17:52                   ` Ævar Arnfjörð Bjarmason
2023-01-12 21:54                   ` Jeff King
2023-01-13  8:28                     ` Ævar Arnfjörð Bjarmason
2023-01-13 17:19                       ` Junio C Hamano
2023-01-14  6:44                         ` René Scharfe
2023-01-14  8:31                           ` René Scharfe
2023-01-14 12:45                             ` Diomidis Spinellis
2023-01-14 16:08                               ` Junio C Hamano
2023-01-13 17:24                       ` René Scharfe
2023-01-13 23:03                         ` René Scharfe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y7flVcALZQgz0VPl@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=l.s.r@web.de \
    --cc=marco.nenciarini@enterprisedb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).