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: > > > > From: Derrick Stolee <dstolee@xxxxxxxxxxxxx> > > > > The recently-implemented expand_to_path() method can supply position > > queries a faster response if they are specifically asking for a path > > within the sparse cone. Since this is the most-common scenario, this > > provides a significant speedup. > > > > Update t1092-sparse-checkout-compatibility.sh to fully ensure that 'git > > status' does not expand a sparse index to a full one, even when there > > exist untracked files. > > > > The performance test script p2000-sparse-operations.sh demonstrates > > that this is the final hole to fill to allow 'git status' to speed up > > when using a sparse index: > > > > 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% > > ? > > > > > Signed-off-by: Derrick Stolee <dstolee@xxxxxxxxxxxxx> > > --- > > t/t1092-sparse-checkout-compatibility.sh | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/t/t1092-sparse-checkout-compatibility.sh b/t/t1092-sparse-checkout-compatibility.sh > > index 380a085f8ec4..b937d7096afd 100755 > > --- a/t/t1092-sparse-checkout-compatibility.sh > > +++ b/t/t1092-sparse-checkout-compatibility.sh > > @@ -456,8 +456,9 @@ test_expect_success 'sparse-index is not expanded' ' > > init_repos && > > > > rm -f trace2.txt && > > + echo >>sparse-index/untracked.txt && > > GIT_TRACE2_EVENT="$(pwd)/trace2.txt" GIT_TRACE2_EVENT_NESTING=10 \ > > - git -C sparse-index status -uno && > > + git -C sparse-index status && > > test_region ! index ensure_full_index trace2.txt > > ' > > > > -- > > gitgitgadget > > 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?
