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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/31/2015 01:23 AM, Junio C Hamano wrote:
Mostyn Bramley-Moore <mostynb@xxxxxxxxx> 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.

There is a hint: --foo-pattern-type applies only to --foo.

In your mgrep example --match-pattern-type would apply to --match patterns only, and if we choose to implement it then --refs-pattern-type would apply to --refs patterns only.

eg:
$ git mgrep --match '^foo' --match-pattern-type=perl-regexp --refs 'release_*' --refs-pattern-type=glob

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".

I hadn't seen the pathspec magic patterns before- interesting. We could possibly share syntax with pathspecs, ie
:(?pattern-options...)pattern

Would this be confusing for commands that already have --perl-regexp etc? What should happen if you specify both --perl-regexp and and a different type of pattern like :(glob)foo (error out, I suppose)?


-Mostyn.
--
Mostyn Bramley-Moore
TV and Connected Devices
Opera Software ASA
mostynb@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]