Re: grep --no-index and pathspec

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Feb 12, 2011, 08:14 UTC
Message-ID: <AANLkTikG1C=7NRGoi+HWz8rE9RN8-pF6o0=S29GZA3eK@mail.gmail.com>
In-Reply-To: <7vwrl6z20p.fsf@alter.siamese.dyndns.org>

2011/2/12 Junio C Hamano <gitster@pobox.com>:

Show 7 quoted lines

> 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?

Because it was designed so? Quotes from 9fc42d6 (Optimize directory listing with pathspec limiter. - 2007-03-30), which added simplify_away(), the function that does pathspec filtering for fill_directory():

    NOTE! This does *not* obviate the need for the caller to do the *exact*
    pathspec match later. It's a first-level filter on "read_directory()", but
    it does not do the full pathspec thing. Maybe it should. But in the
    meantime, builtin-add.c really does need to do first

        read_directory(dir, .., pathspec);
        if (pathspec)
                prune_directory(dir, pathspec, baselen);

    ie the "prune_directory()" part will do the *exact* pathspec pruning,
    while the "read_directory()" will use the pathspec just to do some quick
    high-level pruning of the directories it will recurse into.

Show 11 quoted lines

> @@ -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;

Looks good. We could move prune_directory() from builtin/add.c to dir.c and use it here, but the gain is nothing (except noticing people some pathspecs do not match any).

-- 
Duy