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 g
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 g
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 g
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
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, an
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 http://vger.kernel.org/maj
quot;, 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 line options
> (e.g. --bas
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 have thought th
On Fri, Jul 22, 2016 at 12:51:00PM -0700, Junio C Hamano wrote:
> Jeff King 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.
Jeff King 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 probably need to be depr
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
iced 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 these:
* "git -c gr
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 al
Jeff King 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.patternT
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
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 submit
ode 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 Ex
gt; 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
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 com
This addition makes
>>
>> 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
Jeff King writes:
> On Thu, Oct 04, 2012 at 09:46:42AM -0700, Junio C Hamano wrote:
>
>> Jeff King 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 (sinc
On Thu, Oct 04, 2012 at 09:46:42AM -0700, Junio C Hamano wrote:
> Jeff King 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
Jeff King 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" would
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=''" honors the user
> preference without an explicit -P from the command line.
>
> Now that the c
> >
> > 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 configurati
Read grep.extendedregexp, grep.patterntype, etc. from the
configuration so that "log --grep=''" 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 "
Junio C Hamano writes:
> Junio C Hamano 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)"
>
> wor
Junio C Hamano 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&quo
On Fri, Aug 3, 2012 at 12:39 PM, Junio C Hamano wrote:
>
> Much nicer than the drafts in earlier discussion. One micronit is
> that probably it is preferrable to do '!=' instead of '>', as we are
> only trying to see if it is unspecified on the command line (hence
> need to pay attention to confi
options, add a grep.patternType setting that
> can accept appropriate values for modifying the default grep pattern
> matching behavior. The current values are "basic", "extended", "fixed",
> "perl" and "default" for setting -G, -E, -F, -P and the de
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
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.extendedRegex
o the default settings, say
on a per-repo 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
&g
ult. This
>> +option is ignored when 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 ambigu
J Smith 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
&g
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",
On 2012-07-31, at 7:22 PM, Junio C Hamano wrote:
> J Smith writes:
>
>> With the addition of the "basic", "extended", "fixed", and "perl"
>> values for the "grep.extendedRegexp" option the name "grep.patternTy
J Smith 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. "gre
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"
remain
39 matches
Mail list logo
