On Tue, Mar 24, 2020 at 12:12 PM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > On 3/24/2020 3:15 AM, Elijah Newren wrote: > > > > On Mon, Mar 23, 2020 at 11:12 PM Matheus Tavares > > <matheus.bernardino@xxxxxx> wrote: > >> > >> Also, if I understand correctly, the index doesn't hold paths to dirs, > >> right? So even if a complete dir is excluded from sparse checkout, we > >> still have to check all its subentries, only to discover that they > >> should all be skipped from the search. However, if we were to check > >> against the sparsity patterns directly (e.g. with the function above), > >> we could skip such directories together with all their entries. > > When in cone mode, we can check if a directory is one of these three > modes: > > 1. Completely contained in the cone (recursive match) > 2. Completely outside the cone > 3. Neither. Keep matching subdirectories. (parent match) > > The clear_ce_flags() code in dir.c includes the matching algorithms > for this. Hopefully you can re-use a lot of it. You may need to extract > some methods to use them from the grep code. Thanks for the pointer! I will take a look at the code in dir.c. > >> diff --git a/t/t7817-grep-sparse-checkout.sh b/t/t7817-grep-sparse-checkout.sh > >> new file mode 100755 > >> index 0000000000..fccf44e829 ... > >> + cat >.git/info/sparse-checkout <<-EOF && > >> + /* > >> + !/b > >> + !/dir > >> + EOF > >> + git sparse-checkout init && > > > > Using `git sparse-checkout init` but then manually writing to > > .git/info/sparse-checkout? Seems like it'd make more sense to use > > `git sparse-checkout set` than writing the patterns directly yourself. > > Also, would prefer to have the examples use cone mode (even if you > > have to add subdirectories), as it makes the testcase a bit easier to > > read and more performant, though neither is a big deal. > > I agree that we should use the builtin so your test script is less > brittle to potential back-end changes to sparse-checkout (none planned). Makes sense! > I do recommend having at least one test with non-cone mode patterns, > especially if you are checking the pattern-matching yourself instead of > relying on the index. OK, I will leave at least one test with non-cone patterns then. Thanks for the comments!