On Fri, Apr 23, 2021 at 2:34 PM Derrick Stolee via GitGitGadget <gitgitgadget@xxxxxxxxx> wrote: > > This is the first "payoff" series in the sparse-index work. It makes 'git > status' very fast when a sparse-index is enabled on a repository with > cone-mode sparse-checkout (and a small populated set). > > This is based on ds/sparse-index-protections AND mt/add-rm-sparse-checkout. > The latter branch is needed because it changes the behavior of 'git add' > around sparse entries, which changes the expectations of a test added in > patch 1. > > The approach here is to audit the places where ensure_full_index() pops up > while doing normal commands with pathspecs within the sparse-checkout > definition. Each of these are checked and tested. In the end, the > sparse-index is integrated with these features: > > * git status > * FS Monitor index extension. > > The performance tests in p2000-sparse-operations.sh improve by 95% or more, > even when compared with the full-index cases, not just the sparse-index > cases that previously had extra overhead. > > Hopefully this is the first example of how ds/sparse-index-protections has > done the basic work to do these conversions safely, making them look easier > than they seemed when starting this adventure. > > Thanks, -Stolee > > > Updates in V2 > ============= > > * Based on the feedback, it is clear that 'git add' will require much more > careful testing and thought. I'm splitting it out of this series and it > will return with a follow-up. > * Test cases are improved, both in coverage and organization. > * The previous "unpack-trees: make sparse aware" patch is split into three > now. > * Stale messages based on an old implementation of the "protections" topic > are now fixed. > * Performance tests were re-run. I read through the topic, both my old comments, the range-diff, and the new patches where the range-diff wasn't enough. I tried to spot issues, and was hoping to find problems you alluded to in your recent comments at https://lore.kernel.org/git/05932ebc-04ac-b3c5-a460-5d37d8604fd9@xxxxxxxxx/, but I failed to spot them. I hope it has to do with the cache bottom stuff that I just don't understand, because otherwise I just missed the problems in my review. I can say that in v2 you fixed the issues I did spot in my review of v1. I'll look forward to v3 to see what it was I missed. If I somehow don't respond soon (in a week at the latest), do feel free to ping me; sorry for somehow having this one slip through the cracks.
