On Wed, Oct 3, 2012 at 6:14 PM, Junio C Hamano wrote:
> 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)"
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
rnType is set to a value other than "default", the
grep.extendedRegexp setting is ignored. The value of "default" restores
the current default behavior, including the grep.extendedRegexp
behavior.
Signed-off-by: J Smith
---
Documentation/config.txt | 10 ++-
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 this func
On Wed, Aug 1, 2012 at 5:55 PM, Junio C Hamano wrote:
>
> As the basic structure and the direction looks good, let's start
> nitpicking ;-)
Sounds good.
> We tend to write the commit log message in imperative mood, as if
> you are giving an order to the codebase to "behave this way!". Also
> we
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
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
On Tue, Jul 31, 2012 at 5:05 PM, Junio C Hamano wrote:
>
> Ok, then grep.patternType it is.
>
> Thanks.
Cool, patches should be on their way. I added options for "basic",
"extended", "fixed" and "perl" for completeness along with the name
change with a BC alias patch separately for perusal.
Chee
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 compatibili
Adds "basic", "extended", "fixed", and "perl" settings to the
grep.extendedRegexp configuration option which set "--basic-regexp",
"--extended-regexp", "--fixed-strings", and "--perl-regexp" options by
default respectively. For the purposes of backwards compatibility,
"extended" is equivalent to "t
On Tue, Jul 31, 2012 at 4:30 PM, Junio C Hamano wrote:
> J Smith writes:
>
>> ... For the sake of completeness (verbosity? pedantry?) I also
>> included a setting for "extended" which is equivalent to true.
>
> Good thinking.
>
>> With this sort of ch
On Tue, Jul 31, 2012 at 2:04 PM, Junio C Hamano wrote:
>
> Turning "grep.extendedregexp" from boolean to an extended boolean to
> allow "grep.extendedregexp = perl" might be a better alternative.
> That way, the user wouldn't have to worry about 7 variants of
> grep.fooRegexp variables twenty year
Enables the -P flag for perl regexps by default. When both the
perlRegexp and extendedRegexp options are enabled, the last enabled
option wins.
---
Documentation/config.txt | 6 ++
Documentation/git-grep.txt | 6 ++
builtin/grep.c | 17 +++--
t/t7810-grep.sh
13 matches
Mail list logo
