- 13 9月, 2010 1 次提交
-
-
由 Junio C Hamano 提交于
In the olden days, log --author=me --committer=him --grep=this --grep=that used to be turned into: (OR (HEADER-AUTHOR me) (HEADER-COMMITTER him) (PATTERN this) (PATTERN that)) showing my patches that do not have any "this" nor "that", which was totally useless. 80235ba7 ("log --author=me --grep=it" should find intersection, not union, 2010-01-17) improved it greatly to turn the same into: (ALL-MATCH (HEADER-AUTHOR me) (HEADER-COMMITTER him) (OR (PATTERN this) (PATTERN that))) That is, "show only patches by me and committed by him, that have either this or that", which is a lot more natural thing to ask. We however need to be a bit more clever when the user asks more than one "author" (or "committer"); because a commit has only one author (and one committer), they ought to be interpreted as asking for union to be useful. The current implementation simply added another author/committer pattern at the same top-level for ALL-MATCH to insist on matching all, finding nothing. Turn log --author=me --author=her \ --committer=him --committer=you \ --grep=this --grep=that into (ALL-MATCH (OR (HEADER-AUTHOR me) (HEADER-AUTHOR her)) (OR (HEADER-COMMITTER him) (HEADER-COMMITTER you)) (OR (PATTERN this) (PATTERN that))) instead. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 7月, 2010 1 次提交
-
-
由 Jared Hance 提交于
test_must_fail will account for segfaults in git, so it should be used instead of "! git" This patch does not change any of the commands that use pipes. Signed-off-by: NJared Hance <jaredhance@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 6月, 2010 1 次提交
-
-
由 Johannes Schindelin 提交于
This adds an option to open the matching files in the pager, and if the pager happens to be "less" (or "vi") and there is only one grep pattern, it also jumps to the first match right away. The short option was chose as '-O' to avoid clashes with GNU grep's options (as suggested by Junio). So, 'git grep -O abc' is a short form for 'less +/abc $(grep -l abc)' except that it works also with spaces in file names, and it does not start the pager if there was no matching file. [jn: rebased and added tests; with error handling fix from Junio squashed in] Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 6月, 2010 1 次提交
-
-
由 Gary V. Vaughan 提交于
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: NGary V. Vaughan <gary@thewrittenword.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 2月, 2010 1 次提交
-
-
由 Junio C Hamano 提交于
This reverts commit 3c8f6c8c (Revert 30816237 and 7e622650, 2010-02-05) as the issue has been sorted out.
-
- 08 2月, 2010 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 2月, 2010 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 29 1月, 2010 1 次提交
-
-
由 Junio C Hamano 提交于
Name the option "--quiet" not "--quick", document it, and add tests. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 1月, 2010 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 19 1月, 2010 1 次提交
-
-
由 Junio C Hamano 提交于
The original patch that became cfe370c6 (grep: do not segfault when -f is used, 2009-10-16), was made against "maint" or newer branch back then, but the fix addressed the issue that was present as far as in 1.6.4 series. The maintainer backported the patch to the 1.6.4 maintenance branch, but failed to notice that the new tests assumed the setup done by the script in "maint", which did quite a lot more than the same test script in 1.6.4 series, and the output didn't match the expected result. This should fix it. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 1月, 2010 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 13 1月, 2010 1 次提交
-
-
由 Junio C Hamano 提交于
We still allow people to pass --[no-]ext-grep on the command line, but the option is ignored. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 1月, 2010 2 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 11月, 2009 1 次提交
-
-
由 René Scharfe 提交于
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: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 11月, 2009 1 次提交
-
-
由 Brian Collins 提交于
"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: NJeff King <peff@peff.net> Signed-off-by: NBrian Collins <bricollins@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 10月, 2009 1 次提交
-
-
由 Matt Kraai 提交于
"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: NMatt Kraai <kraai@ftbfs.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 9月, 2009 1 次提交
-
-
由 Clemens Buchacher 提交于
"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: NClemens Buchacher <drizzd@aon.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 7月, 2009 1 次提交
-
-
由 Michał Kiedrowicz 提交于
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: NMichał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 7月, 2009 3 次提交
-
-
由 René Scharfe 提交于
Respect the userdiff attributes and config settings when looking for lines with function definitions in git grep -p. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 René Scharfe 提交于
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: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 René Scharfe 提交于
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: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 6月, 2009 1 次提交
-
-
由 Thomas Rast 提交于
Signed-off-by: NThomas Rast <trast@student.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 5月, 2009 1 次提交
-
-
由 René Scharfe 提交于
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 fb62eb7f ("grep -w: forward to next possible position after rejected match"). Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 4月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 12月, 2008 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
"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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 10月, 2008 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Tested-by: NMike Ralphson <mike@abacus.co.uk> Tested-by: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 05 9月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 02 2月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 15 9月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 12 8月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 06 8月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-