From: Mostyn Bramley-Moore <mostynb@opera.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Duy Nguyen <pclouds@gmail.com>,
"brian m . carlson" <sandals@crustytoothpaste.net>
Subject: Re: [PATCH/RFC v2 0/2] add regex match flags to git describe
Date: Thu, 31 Dec 2015 11:07:29 +0100 [thread overview]
Message-ID: <5684FE61.4010701@opera.com> (raw)
In-Reply-To: <xmqqy4cbbh5e.fsf@gitster.mtv.corp.google.com>
On 12/31/2015 01:23 AM, Junio C Hamano wrote:
> Mostyn Bramley-Moore <mostynb@opera.com> 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@opera.com
next prev parent reply other threads:[~2015-12-31 10:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-28 10:30 [PATCH/RFC v2 0/2] add regex match flags to git describe Mostyn Bramley-Moore
2015-12-28 10:30 ` [PATCH/RFC v2 1/2] describe: add option to use perl-compatible regexes with --match Mostyn Bramley-Moore
2015-12-28 10:30 ` [PATCH/RFC v2 2/2] describe: add basic and extended posix regex matching for completeness Mostyn Bramley-Moore
2015-12-28 20:30 ` [PATCH/RFC v2 0/2] add regex match flags to git describe Junio C Hamano
2015-12-29 0:13 ` Mostyn Bramley-Moore
2015-12-29 18:27 ` Junio C Hamano
2015-12-30 9:52 ` Duy Nguyen
2015-12-31 0:08 ` Mostyn Bramley-Moore
2015-12-31 0:00 ` Mostyn Bramley-Moore
2015-12-31 0:23 ` Junio C Hamano
2015-12-31 10:07 ` Mostyn Bramley-Moore [this message]
2016-01-04 17:46 ` Junio C Hamano
2016-01-06 1:08 ` Mostyn Bramley-Moore
2016-01-06 12:23 ` Duy Nguyen
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=5684FE61.4010701@opera.com \
--to=mostynb@opera.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=sandals@crustytoothpaste.net \
/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.