summaryrefslogtreecommitdiff
path: root/t/t7002-grep.sh
AgeCommit message (Collapse)AuthorFilesLines
2010-05-31tests: use "test_cmp", not "diff", when verifying the resultLibravatar Gary V. Vaughan1-8/+8
In tests, call test_cmp rather than raw diff where possible (i.e. if the output does not go to a pipe), to allow the use of, say, 'cmp' when the default 'diff -u' is not compatible with a vendor diff. When that is not possible, use $DIFF, as set in GIT-BUILD-OPTIONS. Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-02Merge branch 'jc/grep-author-all-match-implicit'Libravatar Junio C Hamano1-1/+9
* jc/grep-author-all-match-implicit: "log --author=me --grep=it" should find intersection, not union
2010-02-13Merge branch 'rs/git-dir-cleanup'Libravatar Junio C Hamano1-0/+52
* rs/git-dir-cleanup: Resurrect "git grep --no-index" setenv(GIT_DIR) clean-up Conflicts: builtin-grep.c t/t7002-grep.sh
2010-02-13Resurrect "git grep --no-index"Libravatar Junio C Hamano1-0/+52
This reverts commit 3c8f6c8 (Revert 30816237 and 7e62265, 2010-02-05) as the issue has been sorted out.
2010-02-07accept "git grep -- pattern"Libravatar Jeff King1-0/+33
Currently the only way to "quote" a grep pattern that might begin with a dash is to use "git grep -e pattern". This works just fine, and is also the way right way to do it on many traditional grep implemenations. Some people prefer to use "git grep -- pattern", however, as "--" is the usual "end of options" marker, and at least GNU grep and Solaris 10 grep support this. This patch makes that syntax work. There is a slight behavior change, in that "git grep -- $X" used to be interpreted as "grep for -- in $X". However, that usage is questionable. "--" is usually the end-of-options marker, so "git grep" was unlike many other greps in treating it as a literal pattern (e.g., both GNU grep and Solaris 10 grep will treat "grep --" as missing a pattern). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-05Revert 30816237 and 7e62265Libravatar Junio C Hamano1-52/+0
It seems that we have bad interaction with the code related to GIT_WORK_TREE and "grep --no-index", and broke running grep inside the .git directory. For now, just revert it and resurrect it after 1.7.0 ships. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-28grep --quiet: finishing touchesLibravatar Junio C Hamano1-0/+8
Name the option "--quiet" not "--quick", document it, and add tests. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-25"log --author=me --grep=it" should find intersection, not unionLibravatar Junio C Hamano1-1/+9
Historically, any grep filter in "git log" family of commands were taken as restricting to commits with any of the words in the commit log message. However, the user almost always want to find commits "done by this person on that topic". With "--all-match" option, a series of grep patterns can be turned into a requirement that all of them must produce a match, but that makes it impossible to ask for "done by me, on either this or that" with: log --author=me --committer=him --grep=this --grep=that because it will require both "this" and "that" to appear. Change the "header" parser of grep library to treat the headers specially, and parse it as: (all-match-OR (HEADER-AUTHOR me) (HEADER-COMMITTER him) (OR (PATTERN this) (PATTERN that) ) ) Even though the "log" command line parser doesn't give direct access to the extended grep syntax to group terms with parentheses, this change will cover the majority of the case the users would want. This incidentally revealed that one test in t7002 was bogus. It ran: log --author=Thor --grep=Thu --format='%s' and expected (wrongly) "Thu" to match "Thursday" in the author/committer date, but that would never match, as the timestamp in raw commit buffer does not have the name of the day-of-the-week. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-15grep --no-index: allow use of "git grep" outside a git repositoryLibravatar Junio C Hamano1-0/+52
Just like some people wanted diff features that are not found in other people's diff implementations outside of a git repository and added --no-index mode to the command, this adds --no-index mode to the "git grep" command. Also, inside a git repository, --no-index mode allows you to grep in untracked (but not ignored) files. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-13Merge branch 'nd/sparse'Libravatar Junio C Hamano1-0/+24
* nd/sparse: (25 commits) t7002: test for not using external grep on skip-worktree paths t7002: set test prerequisite "external-grep" if supported grep: do not do external grep on skip-worktree entries commit: correctly respect skip-worktree bit ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID tests: rename duplicate t1009 sparse checkout: inhibit empty worktree Add tests for sparse checkout read-tree: add --no-sparse-checkout to disable sparse checkout support unpack-trees(): ignore worktree check outside checkout area unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout unpack-trees.c: generalize verify_* functions unpack-trees(): add CE_WT_REMOVE to remove on worktree alone Introduce "sparse checkout" dir.c: export excluded_1() and add_excludes_from_file_1() excluded_1(): support exclude files in index unpack-trees(): carry skip-worktree bit over in merged_entry() Read .gitignore from index if it is skip-worktree Avoid writing to buffer in add_excludes_from_file_1() ... Conflicts: .gitignore Documentation/config.txt Documentation/git-update-index.txt Makefile entry.c t/t7002-grep.sh
2010-01-13grep: rip out support for external grepLibravatar Junio C Hamano1-3/+3
We still allow people to pass --[no-]ext-grep on the command line, but the option is ignored. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-06t7002: test for not using external grep on skip-worktree pathsLibravatar Nguyễn Thái Ngọc Duy1-0/+12
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-06t7002: set test prerequisite "external-grep" if supportedLibravatar Nguyễn Thái Ngọc Duy1-0/+12
Add another test to set prerequisite EXTGREP if the current build supports external grep. This can be used to skip external grep only tests on builds that do not support this optimization. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-22Merge branch 'bc/grep-i-F'Libravatar Junio C Hamano1-0/+10
* bc/grep-i-F: grep: Allow case insensitive search of fixed-strings
2009-11-22grep: unset GREP_OPTIONS before spawning external grepLibravatar René Scharfe1-0/+5
While we're at it, also unset GREP_COLOR and GREP_COLORS in case colouring is not enabled, to be on the safe side. The presence of these variables alone is not sufficient to trigger coloured output with GNU grep, but other implementations may behave differently. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-16grep: Allow case insensitive search of fixed-stringsLibravatar Brian Collins1-0/+10
"git grep" currently an error when you combine the -F and -i flags. This isn't in line with how GNU grep handles it. This patch allows the simultaneous use of those flags. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Brian Collins <bricollins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-16Merge branch 'maint-1.6.4' into maintLibravatar Junio C Hamano1-0/+66
* maint-1.6.4: grep: do not segfault when -f is used
2009-10-16grep: do not segfault when -f is usedLibravatar Matt Kraai1-0/+66
"git grep" would segfault if its -f option was used because it would try to use an uninitialized strbuf, so initialize the strbuf. Thanks to Johannes Sixt <j.sixt@viscovery.net> for the help with the test cases. Signed-off-by: Matt Kraai <kraai@ftbfs.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13Merge branch 'maint'Libravatar Junio C Hamano1-0/+17
* maint: GIT 1.6.4.3 svn: properly escape arguments for authors-prog http.c: remove verification of remote packs grep: accept relative paths outside current working directory grep: fix exit status if external_grep() punts Conflicts: GIT-VERSION-GEN RelNotes
2009-09-13Merge branch 'cb/maint-1.6.3-grep-relative-up' into maintLibravatar Junio C Hamano1-0/+17
* cb/maint-1.6.3-grep-relative-up: grep: accept relative paths outside current working directory grep: fix exit status if external_grep() punts Conflicts: t/t7002-grep.sh
2009-09-07grep: accept relative paths outside current working directoryLibravatar Clemens Buchacher1-0/+17
"git grep" would barf at relative paths pointing outside the current working directory (or subdirectories thereof). Use quote_path_relative(), which can handle such cases just fine. [jc: added tests.] Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-22grep: Add --max-depth option.Libravatar Michał Kiedrowicz1-1/+50
It is useful to grep directories non-recursively, e.g. when one wants to look for all files in the toplevel directory, but not in any subdirectory, or in Documentation/, but not in Documentation/technical/. This patch adds support for --max-depth <depth> option to git-grep. If it is given, git-grep descends at most <depth> levels of directories below paths specified on the command line. Note that if path specified on command line contains wildcards, this option makes no sense, e.g. $ git grep -l --max-depth 0 GNU -- 'contrib/*' (note the quotes) will search all files in contrib/, even in subdirectories, because '*' matches all files. Documentation updates, bash-completion and simple test cases are also provided. Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-01grep -p: support user defined regular expressionsLibravatar René Scharfe1-0/+13
Respect the userdiff attributes and config settings when looking for lines with function definitions in git grep -p. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-01grep: add option -p/--show-functionLibravatar René Scharfe1-2/+34
The new option -p instructs git grep to print the previous function definition as a context line, similar to diff -p. Such context lines are marked with an equal sign instead of a dash. This option complements the existing context options -A, -B, -C. Function definitions are detected using the same heuristic that diff uses. User defined regular expressions are not supported, yet. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-01grep: print context hunk marks between filesLibravatar René Scharfe1-0/+22
Print a hunk mark before matches from a new file are shown, in addition to the current behaviour of printing them if lines have been skipped. The result is easier to read, as (presumably unrelated) matches from different files are separated by a hunk mark. GNU grep does the same. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-27Test grep --and/--or/--notLibravatar Thomas Rast1-0/+30
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-23grep: fix word-regexp at the beginning of linesLibravatar René Scharfe1-1/+8
After bol is forwarded, it doesn't represent the beginning of the line any more. This means that the beginning-of-line marker (^) mustn't match, i.e. the regex flag REG_NOTBOL needs to be set. This bug was introduced by fb62eb7fab97cea880ea7fe4f341a4dfad14ab48 ("grep -w: forward to next possible position after rejected match"). Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-28Merge branch 'maint-1.6.0' into maint-1.6.1Libravatar Junio C Hamano1-0/+4
* maint-1.6.0: grep: fix segfault when "git grep '('" is given Documentation: fix a grammatical error in api-builtin.txt builtin-merge: fix a typo in an error message
2009-04-27grep: fix segfault when "git grep '('" is givenLibravatar Linus Torvalds1-0/+4
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-27grep: grep cache entries if they are "assume unchanged"Libravatar Nguyễn Thái Ngọc Duy1-0/+7
"Assume unchanged" bit means "please pretend that I have never touched this file", so if user removes the file, we should not care. This patch teaches "git grep" to use cache version in such situations. External grep case has not been fixed yet. But given that on the platform that CE_VALID bit may be used like Windows, external grep is not available anyway, I would wait for people to raise their hands before touching it. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-30tests: grep portability fixesLibravatar Jeff King1-1/+1
We try to avoid using the "-q" or "-e" options, as they are largely useless, as explained in aadbe44f. There is one exception for "-e" here, which is in t7701 used to produce an "or" of patterns. This can be rewritten as an egrep pattern. This patch also removes use of "grep -F" in favor of the more widely available "fgrep". [sp: Tested on AIX 5.3 by Mike Ralphson, Tested on MinGW by Johannes Sixt] Signed-off-by: Jeff King <peff@peff.net> Tested-by: Mike Ralphson <mike@abacus.co.uk> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-04log --author/--committer: really match only with name partLibravatar Junio C Hamano1-0/+51
When we tried to find commits done by AUTHOR, the first implementation tried to pattern match a line with "^author .*AUTHOR", which later was enhanced to strip leading caret and look for "^author AUTHOR" when the search pattern was anchored at the left end (i.e. --author="^AUTHOR"). This had a few problems: * When looking for fixed strings (e.g. "git log -F --author=x --grep=y"), the regexp internally used "^author .*x" would never match anything; * To match at the end (e.g. "git log --author='google.com>$'"), the generated regexp has to also match the trailing timestamp part the commit header lines have. Also, in order to determine if the '$' at the end means "match at the end of the line" or just a literal dollar sign (probably backslash-quoted), we would need to parse the regexp ourselves. An earlier alternative tried to make sure that a line matches "^author " (to limit by field name) and the user supplied pattern at the same time. While it solved the -F problem by introducing a special override for matching the "^author ", it did not solve the trailing timestamp nor tail match problem. It also would have matched every commit if --author=author was asked for, not because the author's email part had this string, but because every commit header line that talks about the author begins with that field name, regardleses of who wrote it. Instead of piling more hacks on top of hacks, this rethinks the grep machinery that is used to look for strings in the commit header, and makes sure that (1) field name matches literally at the beginning of the line, followed by a SP, and (2) the user supplied pattern is matched against the remainder of the line, excluding the trailing timestamp data. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01Sane use of test_expect_failureLibravatar Junio C Hamano1-2/+2
Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14Split grep arguments in a way that does not requires to add /dev/null.Libravatar Junio C Hamano1-0/+4
In order to (almost) always show the name of the file without relying on "-H" option of GNU grep, we used to add /dev/null to the argument list unless we are doing -l or -L. This caused "/dev/null:0" to show up when -c is given in the output. It is not enough to add -c to the set of options we do not pass /dev/null for. When we have too many files, we invoke grep multiple times and we need to avoid giving a widow filename to the last invocation -- otherwise we will not see the name. This keeps two filenames when the argv[] buffer is about to overflow and we have not finished iterating over the index, so that the last round will always have at least two paths to work with (and not require /dev/null). An obvious and the only exception is when there is only 1 file that is given to the underlying grep, and in that case we avoid passing /dev/null and let the external "grep -c" report only the number of matches. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2006-08-11git-grep: show pathnames relative to the current directoryLibravatar Junio C Hamano1-2/+29
By default, the command shows pathnames relative to the current directory. Use --full-name (the same flag to do so in ls-files) if you want to see the full pathname relative to the project root. This makes it very pleasant to run in Emacs compilation (or "grep-find") buffer. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-06Fix "grep -w"Libravatar Junio C Hamano1-0/+85
We used to find the first match of the pattern and then if the match is not for the entire word, declared that the whole line does not match. But that is wrong. The command "git grep -w -e mmap" should find that a line "foo_mmap bar mmap baz" matches, by tring the second instance of pattern "mmap" on the same line. Problems an earlier round of "fix" had were pointed out by Morten Welinder, which have been incorporated in the t7002 tests. Signed-off-by: Junio C Hamano <junkio@cox.net>