On 4/20/2021 8:53 PM, Elijah Newren wrote: > One more thing: > > On Tue, Apr 20, 2021 at 5:52 PM Elijah Newren <newren@xxxxxxxxx> wrote: >> >> On Tue, Apr 13, 2021 at 7:01 AM Derrick Stolee via GitGitGadget >> <gitgitgadget@xxxxxxxxx> wrote: >>> Test HEAD~1 HEAD >>> ------------------------------------------------------------------------------ >>> 2000.4: git status (sparse-index-v3) 1.50(1.43+0.10) 0.04(0.04+0.03) -97.3% >>> 2000.5: git status (sparse-index-v4) 1.50(1.43+0.10) 0.04(0.03+0.04) -97.3% >> >> Um, I'm confused. In the previous patch you claimed the following speedups: >> >> 2000.4: git status (sparse-index-v3) 2.43(2.33+0.14) 0.04(0.05+0.04) -98.4% >> 2000.5: git status (sparse-index-v4) 2.44(2.35+0.13) 0.05(0.04+0.07) -98.0% >> >> I don't understand why the "Before" for this patch claims 1.50 as the >> initial speed, if the "After" for the last patch was 0.04. Should the >> previous commit message have instead claimed: >> >> 2000.4: git status (sparse-index-v3) 2.43(2.33+0.14) 1.50(1.43+0.10) -38.3% >> 2000.5: git status (sparse-index-v4) 2.44(2.35+0.13) 1.50(1.43+0.10) -38.5% ... >> Oh! So, the previous patch was testing without enumerating untracked >> files (because it did those slowly), whereas this one enumerates >> untracked files and is still able to achieve the same performance? >> This wasn't very clear from the commit message. Maybe I'm just bad at >> reading, but perhaps the commit message could be tweaked slightly to >> make this more clear? > > Why is the subject of this commit "dir: use expand_to_path() ..." if > it only touches t1092-sparse-checkout-compatibility.sh? You are right to be confused. This is another patch that simplified due to refactors in the protections branch. This should just be squashed into the previous. For context: an earlier version inserted ensure_full_index() before every call to index_name_pos() and then this patch swapped that for a call to expand_to_path(). The change in the protections branch was to have index_name_pos() call expand_to_path() itself, preventing the need for these ensure_full_index() calls. Thanks, -Stolee
