summaryrefslogtreecommitdiff
path: root/builtin-grep.c
AgeCommit message (Collapse)Author
2006-05-21remove superflous "const"Alex Riesen
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-17builtin-grep: workaround for non GNU grep.Linus Torvalds
Of course, it still ignores the fact that not all grep's support some of the flags like -F/-L/-A/-C etc, but for those cases, the external grep itself will happily just say "unrecognized option -F" or similar. So with this change, "git grep" should handle all the flags the native grep handles, which is really quite fine. We don't _need_ to expose anything more, and if you do want our extensions, you can get them with "--uncached" and an up-to-date index. No configuration necessary, and we automatically take advantage of any native grep we have, if possible. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-16Fix silly typo in new builtin grepLinus Torvalds
The "-F" flag apparently got mis-translated due to some over-eager copy-paste work into a duplicate "-H" when using the external grep. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15builtin-grep: unparse more command line options.Junio C Hamano
The earlier one to use external grep missed some often used options. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-15builtin-grep: use external grep when we can take advantage of itLinus Torvalds
It's not perfect, but it gets the "git grep some-random-string" down to the good old half-a-second range for the kernel. It should convert more of the argument flags for "grep", that should be trivial to expand (I did a few just as an example). It should also bother to try to return the right "hit" value (which it doesn't, right now - the code is kind of there, but I didn't actually bother to do it _right_). Also, right now it _just_ limits by number of arguments, but it should also strictly speaking limit by total argument size (ie add up the length of the filenames, and do the "exec_grep()" flush call if it's bigger than some random value like 32kB). But I think that it's _conceptually_ doing all the right things, and it seems to work. So maybe somebody else can do some of the final polish. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-10builtin-grep: -F (--fixed-strings)Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-10builtin-grep: -w fixJunio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-10builtin-grep: typofixJunio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-09builtin-grep: tighten argument parsing.Junio C Hamano
I mistyped git grep next -e '"^@"' '*.c' and got many hits that contain "next" without complaint. Obviously what I meant to say was: git grep -e '"^@"' next -- '*.c' This tightens the argument parsing rule a bit: - All "grep" parameters should come first; - If there is no -e nor -f to specify pattern, the first non option string is the parameter; - After that, zero or more revs can follow. - An optional '--' can be present, and is skipped. - All the rest are pathspecs. If '--' was not there, they must be paths that exist in the working tree. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-08Teach -f <file> option to builtin-grep.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-04builtin-grep: -L (--files-without-match).Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-04builtin-grep: binary files -a and -IJunio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-04builtin-grep: terminate correctly at EOFJunio C Hamano
It barfed and segfaulted with an incomplete line. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-03builtin-grep: tighten path wildcard vs tree traversal.Junio C Hamano
The earlier code descended into Documentation/technical when given "Documentation/how*" as the pattern, which was too loose. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-02builtin-grep: support -w (--word-regexp).Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-02builtin-grep: support -c (--count).Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-02builtin-grep: allow more than one patterns.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-02builtin-grep: allow -<n> and -[ABC]<n> notation for context lines.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-02builtin-grep: printf %.*s length is int, not ptrdiff_t.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-01builtin-grep: do not use setup_revisions()Junio C Hamano
Grep may want to grok multiple revisions, but it does not make much sense to walk revisions while doing so. This stops calling the code to parse parameters for the revision walker. The parameter parsing for the optional "-e" option becomes a lot simpler with it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-01builtin-grep: support '-l' option.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-01builtin-grep: wildcard pathspec fixesJunio C Hamano
This tweaks the pathspec wildcard used in builtin-grep to match that of ls-files. With this: git grep -e DEBUG -- '*/Kconfig*' would work like the shell script version, and you could even do: git grep -e DEBUG --cached -- '*/Kconfig*' ;# from index git grep -e DEBUG v2.6.12 -- '*/Kconfig*' ;# from rev Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-01built-in "git grep"Junio C Hamano
This attempts to set up built-in "git grep" to further reduce our dependence on the shell, while at the same time optionally allowing to run grep against object database. You could do funky things like these: git grep --cached -e pattern ;# grep from index git grep -e pattern master ;# or in a rev git grep -e pattern master next ;# or in multiple revs git grep -e pattern pu^@ ;# even like this with an ;# extension from another topic ;-) git grep -e pattern master..next ;# or even from rev ranges git grep -e pattern master~20:Documentation ;# or an arbitrary tree git grep -e pattern next:git-commit.sh ;# or an arbitrary blob Right now, it does not understand and/or obey many options grep should accept, and the pattern must be given with -e option due to the way the parameter parser is structured, both of which obviously need to be fixed for usability. But this is going in the right direction. The shell script version is one of the worst Portability offender in the git barebone Porcelainish; it uses xargs -0 to pass paths around and shell arrays to sift flags and parameters. Signed-off-by: Junio C Hamano <junkio@cox.net>