Subject: Re: [PATCH/RFC v2 0/2] add regex match flags to git describe

From: Junio C Hamano <[email-masked]>
Date: Wed, 30 Dec 2015 16:23:09 -0800

Mostyn Bramley-Moore <[email-masked]> writes:

> OK, brainstorming a bit, how about either of these:
>
> 1)
> --match-pattern-type=<glob|fixed-strings|basic-regexp|extended-regexp|perl-regexp>
>
> It's a bit lengthy (maybe --match-type would be sufficient), but I
> like that the value names are shared with git grep etc option names.
> And it seems future-proof- if we ever need to support different
> pattern types for other arguments, a --foo-pattern-type flag could be
> added and make obvious sense.

Swapping the option key and value may not be a bad idea, but one
problem that the above does not solve, which I outlined in the
message you are responding to, is that "match-pattern-type" does not
give any hint that this is about affecting the match that is done to
"refs", e.g. you cannot tell in

  $ git mgrep --match-pattern-type=perl-regexp -e foo --refs 'release_*'

if the perl-regexp is to be used for matching branch names or for
matching the strings the command looks for in the trees of the
matching branches.

Magic pattern annotation like we do for pathspecs Duy raised may not
be a bad idea, either, and would probably be easier to teach people.
Just like in Perl "(?i)$any_pattern" is a way to introduce the case
insensitive match with $any_pattern, we may be able to pick an
extensible magic syntax and decorate the pattern you would specify
for matching refnames to tell Git what kind of pattern it is, e.g.

  $ git mgrep -P -e foo --refs '/?glob/release_*'

I am not suggesting that we must use /?<pattern type name>/ prefix
as the "extensible magic syntax" here--I am just illustrating what
I mean by "extensible magic syntax".