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