Re: [PATCH] built-in "git grep" (git grip).

Linus Torvalds [off-list ref] writes:

On Tue, 2 May 2006, Junio C Hamano wrote:

quoted

 - The shell-script one, if you use GNU grep, accepts more
   options to grep than what the current built-in one supports.
   Notable ones that are missing: fixed strings (-F), patterns
   from file (-f), count matches (-c), omit filenames (-h),
   skipping binary files (-I, -U), files without match (-L),
   pcre (-P), silent (-q), word expression (-w), NUL (-z).  They
   should be easy to add if somebody cares enough, and I plan to
   do a few myself before pushing it out to "master".

I use "-w" all the time, along with -5 or similar to get context for the 
grep.

Noted; -w is missing; -A/-B/-C are already there so you could
say -C 5 instead, and -<n> should be easy to add.

On a related tangent, ever since I started using the built-in
grep with ls-files like wildcard, I find myself typing something
like this by mistake (this is from my day-job work project that
has src/mx.js and src/mxstyle.css among other things):

	git diff 268a94 -- 'src/mx*'

I am tempted to suggest switching pathspecs used by diff and log
family to do the same wildcarding, perhaps after tightening the
wildcard vs directory prefix logic used in the builtin-grep of
the current "next" tip, which is a bit looser than necessary.

On Tue, 2 May 2006, Junio C Hamano wrote:

On a related tangent, ever since I started using the built-in
grep with ls-files like wildcard, I find myself typing something
like this by mistake (this is from my day-job work project that
has src/mx.js and src/mxstyle.css among other things):

	git diff 268a94 -- 'src/mx*'

I am tempted to suggest switching pathspecs used by diff and log
family to do the same wildcarding, perhaps after tightening the
wildcard vs directory prefix logic used in the builtin-grep of
the current "next" tip, which is a bit looser than necessary.

Yeah, the wildcarding is nice. You need to be very careful about it, 
though, to make sure that you take full advantage of the path 
component optimizations _before_ the wildcards, so that when you do 
something like the above ('src/mx*'), you do the "src/" part with the 
tree-level optimizations, and only the latter part with the pattern 
matching (because you do _not_ want to expand the whole tree when you 
don't want to).

That "ls-files.c" thing already does part of this (that whole "prefix_len" 
thing for the "longest common prefix").

		Linus