[PATCH v4 11/19] grep: make grep.patternType=[pcre|pcre1] a synonym for "perl"

Make the pattern types "pcre" & "pcre1" synonyms for the long-standing "perl" grep.patternType. This change is part of a longer patch series to add pcre2 support to Git. It's nice to be able to performance test PCRE v1 v.s. v2 without having to recompile git, a

[PATCH v3 10/18] grep: make grep.patternType=[pcre|pcre1] a synonym for "perl"

Make the pattern types "pcre" & "pcre1" synonyms for the long-standing "perl" grep.patternType. This change is part of a longer patch series to add pcre2 support to Git. It's nice to be able to performance test PCRE v1 v.s. v2 without having to recompile git, a

[PATCH v2 07/13] grep: make grep.patternType=[pcre|pcre1] a synonym for "perl"

Make the pattern types "pcre" & "pcre1" synonyms for the long-standing "perl" grep.patternType. This change is part of a longer patch series to add pcre2 support to Git. It's nice to be able to performance test PCRE v1 v.s. v2 without having to recompile git, a

Re: [PATCH 08/12] grep: make grep.patternType=[pcre|pcre1] a synonym for "perl"

On Sat, Apr 08, 2017 at 01:25:02PM +, Ævar Arnfjörð Bjarmason wrote: > Make the pattern types "pcre" & "pcre1" synonyms for long-standing > "perl" grep.patternType. > > This change is part of a longer patch series to add pcre2 support to > G

[PATCH 08/12] grep: make grep.patternType=[pcre|pcre1] a synonym for "perl"

Make the pattern types "pcre" & "pcre1" synonyms for long-standing "perl" grep.patternType. This change is part of a longer patch series to add pcre2 support to Git. It's nice to be able to performance test PCRE v1 v.s. v2 without having to recompile git, and doi

Re: git-prompt.sh incompatible with non-basic global grep.patternType

Eric Sunshine writes: >> Later when the grep API was used in revision graversal machinery, > > s/graversal/traversal/ Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: git-prompt.sh incompatible with non-basic global grep.patternType

ptions as > "git grep", 2012-10-03), instead of setting the .pattern_type_option > field and letting the grep_commit_pattern_type() to take care of the > details. > > This caused an unnecessary bug that made a configured > grep.patternType take precedence over the command

Re: git-prompt.sh incompatible with non-basic global grep.patternType

Jeff King writes: > But even that is a lesser breakage than taking away grep.extendedRegexp > entirely. Taking it away breaks anybody who uses it; tweaking (2) only > breaks people who set both config variables. But why would anyone do > that? OK. Now we have an evidence that we

Re: git-prompt.sh incompatible with non-basic global grep.patternType

On Fri, Jul 22, 2016 at 12:51:00PM -0700, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > >> This comes from b22520a3 (grep: allow -E and -n to be turned on by > >> default via configuration, 2011-03-30) back when we didn't have a > >> more

Re: git-prompt.sh incompatible with non-basic global grep.patternType

Jeff King <p...@peff.net> writes: >> This comes from b22520a3 (grep: allow -E and -n to be turned on by >> default via configuration, 2011-03-30) back when we didn't have a >> more generic grep.patternType configuration mechanism in v1.7.5 >> days, and it

Re: git-prompt.sh incompatible with non-basic global grep.patternType

the command line option or grep.patternType, e.g. > t7810-grep expects crazy things like these: > > * "git -c grep.extendedregexp=true -c grep.patterntype=basic grep" >wants to be like "git grep -E" > > * "git -c grep.extendedregexp=false -c grep.pat

Re: git-prompt.sh incompatible with non-basic global grep.patternType

One thing that I noticed is that there is this strange field in grep_opt called .extended_regexp_option; it only is set from the boolean configuration grep.extendedregexp and worse yet it takes precedence over the command line option or grep.patternType, e.g. t7810-grep expects crazy things like

Re: git-prompt.sh incompatible with non-basic global grep.patternType

On Wed, Jul 20, 2016 at 01:10:42PM -0700, Junio C Hamano wrote: > This may fix it. I think the root cause is that logic to smear > "pattern type" into various broken-down fields in grep_opt for the > short-hands like --basic-regexp option needs to leave "I am setting > this short-hand" mark to

Re: git-prompt.sh incompatible with non-basic global grep.patternType

Jeff King <p...@peff.net> writes: > On Mon, Jul 18, 2016 at 03:56:09PM -0700, Richard Soderberg wrote: > >> ps. git log --basic-regexp does not fix the issue, as for unknown >> reasons (I'll start another thread) the command-line option doesn't >> override grep.pat

Re: git-prompt.sh incompatible with non-basic global grep.patternType

On Mon, Jul 18, 2016 at 03:56:09PM -0700, Richard Soderberg wrote: > ps. git log --basic-regexp does not fix the issue, as for unknown > reasons (I'll start another thread) the command-line option doesn't > override grep.patternType. Dscho gave a fix for your immediate issue, but

Re: git-prompt.sh incompatible with non-basic global grep.patternType

Hi Richard, On Tue, 19 Jul 2016, Richard Soderberg wrote: > Aha! Yes, this works precisely as intended: the prompt works > correctly, and quickly, with this change in place. Okay, next step for you: read http://github.com/git-for-windows/git/blob/master/Documentation/SubmittingPatches and

Re: git-prompt.sh incompatible with non-basic global grep.patternType

ommit, someone added a useful chunk of code that works >> perfectly with svn+ssh:// URLs under basic regexes: >> >> + local svn_upstream=($(git log --first-parent -1 \ + >> --grep="^git-svn-id: \(${svn_url_pattern:2}\)" 2>/dev/null)) >> >> H

Re: git-prompt.sh incompatible with non-basic global grep.patternType

; > However, if I switch over to Perl regexes (or Extended): > > git config --global grep.patternType perl > > Then the command runs for one wall clock second and shows incorrect > results on my repository. I eventually traced this to an issue with the > regular expression provi

git-prompt.sh incompatible with non-basic global grep.patternType

that works perfectly with svn+ssh:// URLs under basic regexes: + local svn_upstream=($(git log --first-parent -1 \ + --grep="^git-svn-id: \(${svn_url_pattern:2}\)" 2>/dev/null)) However, if I switch over to Perl regexes (or Extended): git config --global grep.patternType perl Then the

Re: grep.patternType

git grep -e (integer|buffer) work as expected, when grep.patternType is set to extended. Should this git log --grep=(integer|buffer) also honor the same configuration variable? If not, why not? One more thing. Currently you can say git log -E --grep=(integer|buffer) to ask

Re: grep.patternType

|buffer) work as expected, when grep.patternType is set to extended. Should this git log --grep=(integer|buffer) also honor the same configuration variable? If not, why not? I think this should respect grep.patternType. One more thing. Currently you can say git log -E

Re: [PATCH 6/6] log --grep: honor grep.patterntype etc. configuration variables

On Wed, Oct 03, 2012 at 06:33:39PM -0700, Junio C Hamano wrote: Read grep.extendedregexp, grep.patterntype, etc. from the configuration so that log --grep='pcre' honors the user preference without an explicit -P from the command line. Now that the callback parameter, which was so far unused

Re: [PATCH 6/6] log --grep: honor grep.patterntype etc. configuration variables

Jeff King p...@peff.net writes: Hmm. So I think this is a nice feature for some people, but I wonder if we would run into any plumbing compatibility issues. People do tend to use log as plumbing (since rev-list is not as capable). On the other hand, I'd think most internal uses of log --grep

Re: [PATCH 6/6] log --grep: honor grep.patterntype etc. configuration variables

On Thu, Oct 04, 2012 at 09:46:42AM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: Hmm. So I think this is a nice feature for some people, but I wonder if we would run into any plumbing compatibility issues. People do tend to use log as plumbing (since rev-list is not as

Re: [PATCH 6/6] log --grep: honor grep.patterntype etc. configuration variables

Jeff King p...@peff.net writes: On Thu, Oct 04, 2012 at 09:46:42AM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: Hmm. So I think this is a nice feature for some people, but I wonder if we would run into any plumbing compatibility issues. People do tend to use log as

grep.patternType (was: Re: [ANNOUNCE] Git v1.8.0-rc0)

Junio C Hamano gits...@pobox.com writes: * git grep learned to use a non-standard pattern type by default if a configuration variable tells it to. This addition makes git grep -e (integer|buffer) work as expected, when grep.patternType is set to extended. Should this git log

Re: grep.patternType

Junio C Hamano gits...@pobox.com writes: Junio C Hamano gits...@pobox.com writes: * git grep learned to use a non-standard pattern type by default if a configuration variable tells it to. This addition makes git grep -e (integer|buffer) work as expected, when grep.patternType

[PATCH 6/6] log --grep: honor grep.patterntype etc. configuration variables

Read grep.extendedregexp, grep.patterntype, etc. from the configuration so that log --grep='pcre' honors the user preference without an explicit -P from the command line. Now that the callback parameter, which was so far unused, to git_log_config() has to be of type struct rev_info *, stop

[PATCH/RFC] grep: add a grep.patternType configuration setting

The grep.extendedRegexp configuration setting enables the -E flag on grep by default but there are no equivalents for the -G, -F and -P flags. Rather than adding an additional setting for grep.fooRegexp for current and future pattern matching options, add a grep.patternType setting that can

Re: [PATCH/RFC] grep: add a grep.patternType configuration setting

Alright, I have revised the patch and fixed up the nits that were picked and made a quick modification. I've added a setting for grep.patternType for default which can restore the default grep pattern matching behaviour and restores the functionality back to grep.extendedRegexp. I added

[PATCH/RFC] grep: add a grep.patternType configuration setting

Adds the grep.patternType configuration setting which sets the default pattern matching behavior. The values basic, extended, fixed, and perl can be used to set --basic-regexp, --extended-regexp, --fixed-strings, and --perl-regexp options by default respectively. A value of true is equivalent

Re: [PATCH/RFC] grep: add a grep.patternType configuration setting

J Smith dark.pa...@gmail.com writes: As the basic structure and the direction looks good, let's start nitpicking ;-) Adds the grep.patternType configuration setting which sets the default pattern matching behavior. The values basic, extended, fixed, and perl can be used to set --basic-regexp

Re: [PATCH/RFC] grep: add a grep.patternType configuration setting

the 'grep.patternType' option is set. We are not going to make grep.patternType a boolean, so when ... is set is fine, but if we were to allow grep.patternType to be set to false, the description gives ambiguity to some readers who do. Perhaps s/is set/is given/ is safer. I'm not a native speaker

Re: [PATCH/RFC] grep: add a grep.patternType configuration setting

basis to override a global setting. I was thinking that a false value could provide that, but perhaps a value of default would make more sense? You want a test that runs git -c grep.patternType=basic grep -P or something, guarded with LIBPCRE prerequisite, to make sure pcre patterns are used because

[PATCH/RFC 2/2] grep: rename grep.extendedRegexp option to grep.patternType

With the addition of the basic, extended, fixed, and perl values for the grep.extendedRegexp option the name grep.patternType better represents the option's functionality. grep.extendedRegexp remains available as an alias to grep.patternType for the purposes of backwards compatibility

Re: [PATCH/RFC 2/2] grep: rename grep.extendedRegexp option to grep.patternType

J Smith dark.pa...@gmail.com writes: With the addition of the basic, extended, fixed, and perl values for the grep.extendedRegexp option the name grep.patternType better represents the option's functionality. grep.extendedRegexp remains available as an alias to grep.patternType