Re: grep --no-index and pathspec
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 11, 2011, 21:37 UTC
- Message-ID
- <7vwrl6z20p.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <7v8vxm1l6q.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 16 quoted lines
> Michael J Gruber <git@drmicha.warpmail.net> writes: > >> "grep --no-index" and "grep" have different codepaths for looking up the >> files/blobs. If I read that correctly then "grep --no-index -- pathspec" >> only does a literal match at the left boundary, whereas for the normal >> mode glob patterns are allowed. >> >> CC'ing Junio who created "--no-index". > > Anything with --no-index is a quick hack, so I wouldn't be surprised if it > ignored the normal pathspec logic. As I do not recall the details of the > particular codepath and offhand do not know how involved a change to pay > proper attention to the pathspecs would be, but I suspect that it would be > more appropriate to fix it on top of nd/struct-pathspec topic than writing > the current behaviour down in the documentation outside of BUGS section as > if it were a feature ;-).
This is a band-aid modelled after what builtin/clean.c does to the returned list from fill_directory(), and it seems to do its job, but I am quite unhappy about it.
The function fill_directory() already takes a pathspec, albeit in the degenerate "const char **" form. Why does its output need further filtering?
builtin/grep.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c index c3af876..5afee2f 100644 --- a/builtin/grep.c +++ b/builtin/grep.c @@ -626,6 +626,10 @@ static int grep_directory(struct grep_opt *opt, const struct pathspec *pathspec) fill_directory(&dir, pathspec->raw); for (i = 0; i < dir.nr; i++) { + const char *name = dir.entries[i]->name; + int namelen = strlen(name); + if (!match_pathspec_depth(pathspec, name, namelen, 0, NULL)) + continue; hit |= grep_file(opt, dir.entries[i]->name); if (hit && opt->status_only) break;