All of lore.kernel.org
 help / color / mirror / 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: Wed, 4 Jan 2023 02:46:39 -0500	[thread overview]
Message-ID: <Y7Uu35HwUx2EVfAg@coredump.intra.peff.net> (raw)
In-Reply-To: <343a891e-d737-0ace-26a9-3839d3bd5583@web.de>

On Tue, Jan 03, 2023 at 09:52:27PM +0100, René Scharfe wrote:

> diff --git a/Makefile b/Makefile
> index db447d0738..15e7edc9d2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -289,6 +289,10 @@ include shared.mak
>  # Define NO_REGEX if your C library lacks regex support with REG_STARTEND
>  # feature.
>  #
> +# Define GIT_GREP_USES_REG_ENHANCED if your C library provides the flag
> +# REG_ENHANCED to enable enhanced basic regular expressions and you'd
> +# like to use it in git grep.

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?

-Peff

  parent reply	other threads:[~2023-01-04  7:46 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 [this message]
2023-01-04 16:36         ` René Scharfe
2023-01-06  9:09           ` Jeff King
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

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

  git send-email \
    --in-reply-to=Y7Uu35HwUx2EVfAg@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.