On Mon, May 11, 2020 at 4:35 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Matheus Tavares <matheus.bernardino@xxxxxx> writes:
>
> > One of the main uses for a sparse checkout is to allow users to focus on
> > the subset of files in a repository in which they are interested. But
> > git-grep currently ignores the sparsity patterns and report all matches
> > found outside this subset, which kind of goes in the opposite direction.
> > Let's fix that, making it honor the sparsity boundaries for every
> > grepping case:
> >
> > - git grep in worktree
> > - git grep --cached
> > - git grep $REVISION
>
> It makes sense for these to be limited within the "sparse" area.
>
> > - git grep --untracked and git grep --no-index (which already respect
> > sparse checkout boundaries)
>
> I can understand the former; those untracked files are what _could_
> be brought into attention by "git add", so limiting to the same
> "sparse" area may make sense.
>
> I am not sure about the latter, though, as "--no-index" is an
> explicit request to pretend that we are dealing with a random
> collection of files, not managed in a git repository. But perhaps
> there is a similar justification like how "--untracked" is
> unjustifiable. I dunno.
Yeah, I think there was no need to mention those two cases here. My
intention was to say that, in these cases, we should stick to the
files that are present in the working tree (which should match the
sparsity patterns + untracked {and ignored, in --no-index}), as
opposed to how the worktree grep used to behave until now, falling
back to the cache on files excluded by the sparse checkout.
> > diff --git a/builtin/grep.c b/builtin/grep.c
> > index a5056f395a..91ee0b2734 100644
> > --- a/builtin/grep.c
> > +++ b/builtin/grep.c
> > @@ -410,7 +410,7 @@ static int grep_cache(struct grep_opt *opt,
> > const struct pathspec *pathspec, int cached);
> > static int grep_tree(struct grep_opt *opt, const struct pathspec *pathspec,
> > struct tree_desc *tree, struct strbuf *base, int tn_len,
> > - int check_attr);
> > + int is_root_tree);
> >
> > static int grep_submodule(struct grep_opt *opt,
> > const struct pathspec *pathspec,
> > @@ -508,6 +508,10 @@ static int grep_cache(struct grep_opt *opt,
> >
> > for (nr = 0; nr < repo->index->cache_nr; nr++) {
> > const struct cache_entry *ce = repo->index->cache[nr];
> > +
> > + if (ce_skip_worktree(ce) && !S_ISGITLINK(ce->ce_mode))
> > + continue;
>
> Hmph. Why exclude gitlink from this rule? If a submodule sits at a
> path that is excluded by the sparse pattern, should we still recurse
> into it?
The idea behind not skipping gitlinks here was to be compliant with
what we have in the working tree. In 4fd683b ("sparse-checkout:
document interactions with submodules"), we decided that, if the
sparse-checkout patterns exclude a submodule, the submodule would
still appear in the working tree. The purpose was to keep these
features (submodules and sparse-checkout) independent. Along the same
lines, I think we should always recurse into initialized submodules in
grep, and then load their own sparsity patterns, to decide what should
be grepped within.
[...]
> > +static int grep_tree(struct grep_opt *opt, const struct pathspec *pathspec,
> > + struct tree_desc *tree, struct strbuf *base, int tn_len,
> > + int is_root_tree)
> > +{
> > + struct pattern_list *patterns = NULL;
> > + int ret;
> > +
> > + if (is_root_tree)
> > + patterns = get_sparsity_patterns(opt->repo);
> > +
> > + ret = do_grep_tree(opt, pathspec, tree, base, tn_len, is_root_tree,
> > + patterns, 0);
> > +
> > + if (patterns) {
> > + clear_pattern_list(patterns);
> > + free(patterns);
> > + }
>
> OK, it is not like this codepath is driven by "git log" to grep from
> top-level tree objects of many commits, so it is OK to grab the
> sparsity patterns once before do_grep_tree() and discard it when we
> are done.
Yeah. A possible performance problem here would be when users pass
many trees to git-grep (since we are reloading the pattern lists, from
both the_repository and submodules, for each tree). But, as Elijah
pointed out [1], the cases where this overhead might be somewhat
noticeable should be very rare.
[1]: https://lore.kernel.org/git/CABPp-BGUf-4exGW23xka1twf2D=nFOz1CkD_f-rDX_AGdVEeDA@xxxxxxxxxxxxxx/
