Re: [PATCH v2 0/8] Sparse-index: integrate with status
From: Elijah Newren <hidden>
Date: 2021-05-13 04:12:48
On Fri, Apr 23, 2021 at 2:34 PM Derrick Stolee via GitGitGadget [off-list ref] 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@gmail.com/ (local), 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.