summaryrefslogtreecommitdiff
path: root/t/t7810-grep.sh
AgeCommit message (Collapse)AuthorFilesLines
2017-01-23Merge branch 'jk/grep-e-could-be-extended-beyond-posix'Libravatar Junio C Hamano1-11/+15
Tighten a test to avoid mistaking an extended ERE regexp engine as a PRE regexp engine. * jk/grep-e-could-be-extended-beyond-posix: t7810: avoid assumption about invalid regex syntax
2017-01-11t7810: avoid assumption about invalid regex syntaxLibravatar Jeff King1-11/+15
A few of the tests want to check that "git grep -P -E" will override -P with -E, and vice versa. To do so, we use a regex with "\x{..}", which is valid in PCRE but not defined by POSIX (for basic or extended regular expressions). However, POSIX declares quite a lot of syntax, including "\x", as "undefined". That leaves implementations free to extend the standard if they choose. At least one, musl libc, implements "\x" in the same way as PCRE. Our tests check that "-E" complains about "\x", which fails with musl. We can fix this by finding some construct which behaves reliably on both PCRE and POSIX, but differently in each system. One such construct is the use of backslash inside brackets. In PCRE, "[\d]" interprets "\d" as it would outside the brackets, matching a digit. Whereas in POSIX, the backslash must be treated literally, and we match either it or a literal "d". Moreover, implementations are not free to change this according to POSIX, so we should be able to rely on it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11Spelling fixesLibravatar Ville Skyttä1-1/+1
<BAD> <CORRECTED> accidently accidentally commited committed dependancy dependency emtpy empty existance existence explicitely explicitly git-upload-achive git-upload-archive hierachy hierarchy indegee indegree intial initial mulitple multiple non-existant non-existent precendence. precedence. priviledged privileged programatically programmatically psuedo-binary pseudo-binary soemwhere somewhere successfull successful transfering transferring uncommited uncommitted unkown unknown usefull useful writting writing Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-13Merge branch 'nd/ita-cleanup'Libravatar Junio C Hamano1-1/+59
Git does not know what the contents in the index should be for a path added with "git add -N" yet, so "git grep --cached" should not show hits (or show lack of hits, with -L) in such a path, but that logic does not apply to "git grep", i.e. searching in the working tree files. But we did so by mistake, which has been corrected. * nd/ita-cleanup: grep: fix grepping for "intent to add" files t7810-grep.sh: fix a whitespace inconsistency t7810-grep.sh: fix duplicated test name
2016-07-06Merge branch 'cb/t7810-test-label-fix'Libravatar Junio C Hamano1-1/+1
Test clean-up. * cb/t7810-test-label-fix: t7810: fix duplicated test title
2016-07-01grep: fix grepping for "intent to add" filesLibravatar Charles Bailey1-0/+58
This reverts commit 4d5520053 (grep: make it clear i-t-a entries are ignored, 2015-12-27) and adds an alternative fix to maintain the -L --cached behavior. 4d5520053 caused 'git grep' to no longer find matches in new files in the working tree where the corresponding index entry had the "intent to add" bit set, despite the fact that these files are tracked. The content in the index of a file for which the "intent to add" bit is set is considered indeterminate and not empty. For most grep queries we want these to behave the same, however for -L --cached (files without a match) we don't want to respond positively for "intent to add" files as their contents are indeterminate. This is in contrast to files with empty contents in the index (no lines implies no matches for any grep query expression) which should be reported in the output of a grep -L --cached invocation. Add tests to cover this case and a few related cases which previously lacked coverage. Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Charles Bailey <cbailey32@bloomberg.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-01t7810-grep.sh: fix a whitespace inconsistencyLibravatar Charles Bailey1-1/+1
Signed-off-by: Charles Bailey <charles@hashpling.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-01t7810-grep.sh: fix duplicated test nameLibravatar Charles Bailey1-1/+1
Signed-off-by: Charles Bailey <charles@hashpling.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-21t7810: fix duplicated test titleLibravatar Charles Bailey1-1/+1
Signed-off-by: Charles Bailey <charles@hashpling.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20Merge branch 'rs/xdiff-hunk-with-func-line'Libravatar Junio C Hamano1-3/+16
"git show -W" (extend hunks to cover the entire function, delimited by lines that match the "funcname" pattern) used to show the entire file when a change added an entire function at the end of the file, which has been fixed. * rs/xdiff-hunk-with-func-line: xdiff: fix merging of appended hunk with -W grep: -W: don't extend context to trailing empty lines t7810: add test for grep -W and trailing empty context lines xdiff: don't trim common tail with -W xdiff: -W: don't include common trailing empty lines in context xdiff: ignore empty lines before added functions with -W xdiff: handle appended chunks better with -W xdiff: factor out match_func_rec() t4051: rewrite, add more tests
2016-05-31grep: -W: don't extend context to trailing empty linesLibravatar René Scharfe1-1/+1
Empty lines between functions are shown by grep -W, as it considers them to be part of the function preceding them. They are not interesting in most languages. The previous patches stopped showing them for diff -W. Stop showing empty lines trailing a function with grep -W. Grep scans the lines of a buffer from top to bottom and prints matching lines immediately. Thus we need to peek ahead in order to determine if an empty line is part of a function body and worth showing or not. Remember how far ahead we peeked in order to avoid having to do so repeatedly when handling multiple consecutive empty lines. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-31t7810: add test for grep -W and trailing empty context linesLibravatar René Scharfe1-3/+16
Add a test demonstrating that git grep -W prints empty lines following the function context we're actually interested in. The modified test file makes it necessary to adjust three unrelated test cases. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-07grep: turn off gitlink detection for --no-indexLibravatar Jeff King1-0/+27
If we are running "git grep --no-index" outside of a git repository, we behave roughly like "grep -r", examining all files in the current directory and its subdirectories. However, because we use fill_directory() to do the recursion, it will skip over any directories which look like sub-repositories. For a normal git operation (like "git grep" in a repository) this makes sense; we do not want to cross the boundary out of our current repository into a submodule. But for "--no-index" without a repository, we should look at all files, including embedded repositories. There is one exception, though: we probably should _not_ descend into ".git" directories. Doing so is inefficient and unlikely to turn up useful hits. This patch drops our use of dir.c's gitlink-detection, but we do still avoid ".git". That makes us more like tools such as "ack" or "ag", which also know to avoid cruft in .git. As a bonus, this also drops our usage of the ref code when we are outside of a repository, making the transition to pluggable ref backends cleaner. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-12builtin/grep: add grep.fallbackToNoIndex configLibravatar Thomas Gummerer1-0/+41
Currently when git grep is used outside of a git repository without the --no-index option git simply dies. For convenience, add a grep.fallbackToNoIndex configuration variable. If set to true, git grep behaves like git grep --no-index if it is run outside of a git repository. It defaults to false, preserving the current behavior. Helped-by: Jeff King <peff@peff.net> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-11t7810: correct --no-index testLibravatar Thomas Gummerer1-4/+4
GIT_CEILING_DIRECTORIES doesn't prevent chdir up into another directory while looking for a repository directory if it is equal to the current directory. Because of this, the test which claims to test the git grep --no-index command outside of a repository actually tests it inside of a repository. The test_must_fail assertions still pass because the git grep only looks at untracked files and therefore no file matches, but not because it's run outside of a repository as it was originally intended. Set the GIT_CEILING_DIRECTORIES environment variable to the parent directory of the directory in which the git grep command is executed, to make sure it is actually run outside of a git repository. In addition, the && chain was broken in a couple of places in the same test, fix that. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-31Merge branch 'rs/grep-color-words'Libravatar Junio C Hamano1-0/+94
Allow painting or not painting (partial) matches in context lines when showing "grep -C<num>" output in color. * rs/grep-color-words: grep: add color.grep.matchcontext and color.grep.matchselected
2014-10-28grep: add color.grep.matchcontext and color.grep.matchselectedLibravatar René Scharfe1-0/+94
The config option color.grep.match can be used to specify the highlighting color for matching strings. Add the options matchContext and matchSelected to allow different colors to be specified for matching strings in the context vs. in selected lines. This is similar to the ms and mc specifiers in GNU grep's environment variable GREP_COLORS. Tests are from Zoltan Klinger's earlier attempt to solve the same issue in a different way. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-05t/t7810-grep.sh: remove duplicate test_config()Libravatar Jeremiah Mahler1-5/+0
t/t7810-grep.sh had its own test_config() function which served the same purpose as the one in t/test-lib-functions.sh. Removed, all tests pass. Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-11grep: support -h (no header) with --countLibravatar René Scharfe1-0/+12
Suppress printing the header (filename) with -h even if in -c/--count mode. GNU grep and OpenBSD's grep do the same. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-11t7810: add missing variables to tests in loopLibravatar René Scharfe1-29/+29
Some tests in t7810-grep.sh are in a loop that runs them against HEAD and the work tree. In order for that to work the test code should use the variables $L (display name), $H (HEAD or empty string) and $HC (revision prefix for result lines); otherwise tests are just repeated with the same target. Add the variables where they're missing and make sure the test description is wrapped in double quotes (instead of single quotes) to allow variables to be expanded. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29log --grep-reflog: reject the option without -gLibravatar Junio C Hamano1-0/+4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29revision: add --grep-reflog to filter commits by reflog messagesLibravatar Nguyễn Thái Ngọc Duy1-0/+26
Similar to --author/--committer which filters commits by author and committer header fields. --grep-reflog adds a fake "reflog" header to commit and a grep filter to search on that line. All rules to --author/--committer apply except no timestamp stripping. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29grep: prepare for new header field filterLibravatar Nguyễn Thái Ngọc Duy1-0/+12
grep supports only author and committer headers, which have the same special treatment that later headers may or may not have. Check for field type and only strip_timestamp() when the field is either author or committer. GREP_HEADER_FIELD_MAX is put in the grep_header_field enum to be calculated automatically, correctly, as long as it's at the end of the enum. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-18Merge branch 'jc/maint-log-grep-all-match'Libravatar Junio C Hamano1-14/+76
Fix a long-standing bug in "git log --grep" when multiple "--grep" are used together with "--all-match" and "--author" or "--committer". * jc/maint-log-grep-all-match: t7810-grep: test --all-match with multiple --grep and --author options t7810-grep: test interaction of multiple --grep and --author options t7810-grep: test multiple --author with --all-match t7810-grep: test multiple --grep with and without --all-match t7810-grep: bring log --grep tests in common form grep.c: mark private file-scope symbols as static log: document use of multiple commit limiting options log --grep/--author: honor --all-match honored for multiple --grep patterns grep: show --debug output only once grep: teach --debug option to dump the parse tree
2012-09-15t7810-grep: test --all-match with multiple --grep and --author optionsLibravatar Michael J Gruber1-0/+20
The code used to have a bug that ignores "--all-match", that requires all "--grep" to have matched, when "--author" or "--committer" was used. Make sure the bug will not be reintroduced. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-15t7810-grep: test interaction of multiple --grep and --author optionsLibravatar Michael J Gruber1-16/+22
There are tests for this interaction already. Restructure slightly and avoid any claims about --all-match. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-15t7810-grep: test multiple --author with --all-matchLibravatar Michael J Gruber1-0/+8
The "--all-match" option is about "--grep", and does not affect how "--author" or "--committer" limitation is applied. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-15t7810-grep: test multiple --grep with and without --all-matchLibravatar Michael J Gruber1-0/+16
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-15t7810-grep: bring log --grep tests in common formLibravatar Michael J Gruber1-6/+18
The log --grep tests generate the expected out in different ways. Make them all use command blocks so that subshells are avoided and the expected output is easier to grasp visually. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Merge branch 'js/grep-patterntype-config'Libravatar Junio C Hamano1-0/+181
"grep" learned to use a non-standard pattern type by default if a configuration variable tells it to. * js/grep-patterntype-config: grep: add a grep.patternType configuration setting
2012-08-03grep: add a grep.patternType configuration settingLibravatar J Smith1-0/+181
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 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 default behavior respectively. When grep.patternType 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 <dark.panda@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-30Merge branch 'rj/maint-grep-remove-redundant-test'Libravatar Junio C Hamano1-11/+0
"git grep" stopped spawning an external "grep" long time ago, but a duplicated test to check internal and external "grep" was left behind. * rj/maint-grep-remove-redundant-test: t7810-*.sh: Remove redundant test
2012-07-29t7810-*.sh: Remove redundant testLibravatar Ramsay Jones1-11/+0
Since commit bbc09c22 ("grep: rip out support for external grep", 12-01-2010), test number 60 ("grep -C1 hunk mark between files") is essentially the same as test number 59. Test 59 was intended to verify the behaviour of git-grep resulting from multiple invocations of an external grep. As part of the test, it creates and adds 1024 files to the index, which is now wasted effort. Remove test 59, since it is now redundant. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-01Merge branch 'rs/maint-grep-F' into maintLibravatar Junio C Hamano1-0/+5
"git grep -e '$pattern'", unlike the case where the patterns are read from a file, did not treat individual lines in the given pattern argument as separate regular expressions as it should. By René Scharfe * rs/maint-grep-F: grep: stop leaking line strings with -f grep: support newline separated pattern list grep: factor out do_append_grep_pat() grep: factor out create_grep_pat()
2012-05-25Merge branch 'rs/maint-grep-F'Libravatar Junio C Hamano1-0/+5
"git grep -e '$pattern'", unlike the case where the patterns are read from a file, did not treat individual lines in the given pattern argument as separate regular expressions as it should.
2012-05-20grep: support newline separated pattern listLibravatar René Scharfe1-0/+5
Currently, patterns that contain newline characters don't match anything when given to git grep. Regular grep(1) interprets patterns as lists of newline separated search strings instead. Implement this functionality by creating and inserting extra grep_pat structures for patterns consisting of multiple lines when appending to the pattern lists. For simplicity, all pattern strings are duplicated. The original pattern is truncated in place to make it contain only the first line. Requested-by: Torne (Richard Coles) <torne@google.com> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-27grep -P: add tests for matching ^ and $Libravatar Michał Kiedrowicz1-0/+23
Earlier, fba4f1 (grep -P: Fix matching ^ and $) fixed an ancient bug. Add some tests to protect the change from future breakages; a slightly broken version of this was a part of the originally submitted patch. Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-23grep: fix -l/-L interaction with decoration linesLibravatar Albert Yale1-0/+22
In threaded mode, git-grep emits file breaks (enabled with context, -W and --break) into the accumulation buffers even if they are not required. The output collection thread then uses skip_first_line to skip the first such line in the output, which would otherwise be at the very top. This is wrong when the user also specified -l/-L/-c, in which case every line is relevant. While arguably giving these options together doesn't make any sense, git-grep has always quietly accepted it. So do not skip anything in these cases. Signed-off-by: Albert Yale <surfingalbert@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12grep: load funcname patterns for -WLibravatar Thomas Rast1-0/+14
git-grep avoids loading the funcname patterns unless they are needed. ba8ea74 (grep: add option to show whole function as context, 2011-08-01) forgot to extend this test also to the new funcbody feature. Do so. The catch is that we also have to disable threading when using userdiff, as explained in grep_threads_ok(). So we must be careful to introduce the same test there. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-04Merge branch 'jc/maint-grep-untracked-exclude' into jc/grep-untracked-excludeLibravatar Junio C Hamano1-1/+33
* jc/maint-grep-untracked-exclude: grep: teach --untracked and --exclude-standard options grep --no-index: don't use git standard exclusions grep: do not use --index in the short usage output Conflicts: Documentation/git-grep.txt builtin/grep.c
2011-08-01grep: add option to show whole function as contextLibravatar René Scharfe1-0/+14
Add a new option, -W, to show the whole surrounding function of a match. It uses the same regular expressions as -p and diff to find the beginning of sections. Currently it will not display comments in front of a function, but those that are following one. Despite this shortcoming it is already useful, e.g. to simply see a more complete applicable context or to extract whole functions. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-29Merge branch 'rs/grep-color'Libravatar Junio C Hamano1-0/+95
* rs/grep-color: grep: add --heading grep: add --break grep: fix coloring of hunk marks between files
2011-06-20t7810: avoid unportable use of "echo"Libravatar Junio C Hamano1-3/+3
Michael J Gruber noticed that under /bin/dash this test failed (as is expected -- \n in the string can be interpreted by the command), while it passed with bash. We probably could work it around by using backquote in front of it, but it is safer and more readable to avoid "echo" altogether in a case like this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-05grep: add --headingLibravatar René Scharfe1-0/+37
With --heading, the filename is printed once before matches from that file instead of at the start of each line, giving more screen space to the actual search results. This option is taken from ack (http://betterthangrep.com/). And now git grep can dress up like it: $ git config alias.ack "grep --break --heading --line-number" $ git ack -e --heading Documentation/git-grep.txt 154:--heading:: t/t7810-grep.sh 785:test_expect_success 'grep --heading' ' 786: git grep --heading -e char -e lo_w hello.c hello_world >actual && 808: git grep --break --heading -n --color \ Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-05grep: add --breakLibravatar René Scharfe1-0/+28
With --break, an empty line is printed between matches from different files, increasing readability. This option is taken from ack (http://betterthangrep.com/). Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-05grep: fix coloring of hunk marks between filesLibravatar René Scharfe1-0/+30
Commit 431d6e7b (grep: enable threading for context line printing) split the printing of the "--\n" mark between results from different files out into two places: show_line() in grep.c for the non-threaded case and work_done() in builtin/grep.c for the threaded case. Commit 55f638bd (grep: Colorize filename, line number, and separator) updated the former, but not the latter, so the separators between files are not colored if threads are used. This patch merges the two. In the threaded case, hunk marks are now printed by show_line() for every file, including the first one, and the very first mark is simply skipped in work_done(). This ensures that the output is properly colored and works just as well. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-29git-grep: Fix problems with recently added testsLibravatar Michał Kiedrowicz1-32/+26
Brian Gernhardt reported that test 'git grep -E -F -G a\\+b' fails on OS X 10.6.7. This is because I assumed \+ is part of BRE, which isn't true on all platforms. The easiest way to make this test pass is to just update expected output, but that would make the test pointless. Its real purpose is to check whether 'git grep -E -F -G' is different from 'git grep -E -G -F'. To check that, let's change pattern to "a+b*c". This should return different match for -G, -F and -E. I also made two small tweaks to the tests. First, I added path "ab" to all calls to future-proof tests. Second, I updated last two tests to better show that 'git grep -P -E' is different from 'git grep -E -P'. Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-23git-grep: Update tests (mainly for -P)Libravatar Michał Kiedrowicz1-0/+85
Add few more tests for "-P/--perl-regexp" option of "git grep". While at it, add some generic tests for grep.extendedRegexp config option, for detecting invalid regexep and check if "last one wins" rule works for selecting regexp type. Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-16git-grep: update tests now regexp type is "last one wins"Libravatar Junio C Hamano1-16/+0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-09git-grep: Bail out when -P is used with -F or -ELibravatar Michał Kiedrowicz1-0/+16
This patch makes git-grep die() when -P is used on command line together with -E/--extended-regexp or -F/--fixed-strings. This also makes it bail out when grep.extendedRegexp is enabled. But `git grep -G -P pattern` and `git grep -E -G -P pattern` still work because -G and -E set opts.regflags during parse_options() and there is no way to detect `-G` or `-E -G`. Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>