summaryrefslogtreecommitdiff
path: root/git-grep.sh
AgeCommit message (Collapse)AuthorFilesLines
2006-05-16Remove old "git-grep.sh" remnantsLibravatar Linus Torvalds1-62/+0
It's built-in now. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-21git-grep: clarification on parameters.Libravatar Junio C Hamano1-9/+21
We forgot to make sure that there is no more than one pattern parameter. Also when looking for files in a directory called '--others', it passed that path limiter without preceding the end-of-options marker '--' to underlying git-ls-files, which misunderstood it as one of its options instead. $ git grep --others -e Meta/Make Meta $ git grep -o -e Meta/Make Meta $ git grep -o Meta/Make Meta look for a string "Meta/Make" from untracked files in Meta/ directory. $ git grep Meta/Make --others looks for the same string from tracked files in ./--others directory. On the other hand, $ git grep -e Meta/Make --others does not have a freestanding pattern, so everybody is parameter and there is no path specifier. It looks for the string in all the untracked files without any path limiter. [jc: updated with usability enhancements and documentation cleanups from Sean.] Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-14Trivial usage string clean-upLibravatar freku045@student.liu.se1-2/+5
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-16Disallow empty pattern in "git grep"Libravatar Linus Torvalds1-0/+4
For some reason I've done a "git grep" twice with no pattern, which is really irritating, since it just grep everything. If I actually wanted that, I could do "git grep ^" or something. So add a "usage" message if the pattern is empty. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-24git-grep: fix 'git grep -e $pattern' handlingLibravatar Junio C Hamano1-1/+1
People typically say 'grep -e $pattern' because $pattern has a leading dash which would be mistaken as a grep flag. Make sure we pass -e in front of $pattern when we invoke grep. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-12Improve "git grep" flags handlingLibravatar Linus Torvalds1-23/+41
This allows any arbitrary flags to "grep", and knows about the few special grep flags that take an argument too. It also allows some flags for git-ls-files, although their usefulness is questionable. With this, something line git grep -w -1 pattern works, without the script enumerating every possible flag. [jc: this is the version Linus sent out after I showed him a barf-o-meter test version that avoids shell arrays. He must have typed this version blindly, since he said: I'm not barfing, but that's probably because my brain just shut down and is desperately trying to gouge my eyes out with a spoon. I slightly fixed it to catch the remaining arguments meant to be given git-ls-files.] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-12Allow finding things that begin with a dash in 'git grep'Libravatar Junio C Hamano1-1/+6
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-12[PATCH] Add "git grep" helperLibravatar Linus Torvalds1-0/+20
Very convenient shorthand for git-ls-files [file-patterns] | xargs grep <pattern> which I tend to do all the time. Yes, it's trivial, but it's really nice. I can do git grep '\<some_variable\>' arch/i386 include/asm-i386 and it does exactly what you'd think it does. And since it just uses the normal git-ls-files file patterns, you can do things like git grep something 'include/*.h' and it will search all header files under the include/ subdirectory. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>