From: Derrick Stolee <stolee@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
Amisha Chhajed <amishhhaaaa@gmail.com>
Cc: "René Scharfe" <l.s.r@web.de>,
git@vger.kernel.org, newren@gmail.com, peff@peff.net
Subject: Re: [PATCH v3] sparse-checkout: optimize string_list construction
Date: Sat, 17 Jan 2026 21:46:18 -0500 [thread overview]
Message-ID: <c5631f7d-72ff-4876-9b68-ea4a70fde501@gmail.com> (raw)
In-Reply-To: <xmqqy0lx8ojt.fsf@gitster.g>
On 1/16/26 12:17 PM, Junio C Hamano wrote:
> Amisha Chhajed <amishhhaaaa@gmail.com> writes:
>
>> It was assumed to be safe under the notion that our entries are not
>> duplicate but as already pointed out, our entries are not unique so we
>> need one of those two ways either insert or remove_duplicates, this
>> can be a trivial question but i wonder how are the tests passing by
>> removing these lines, i was actually researching about it.
>
> ... suspense. And the result of the research was???
>
> If the answer was simply "we lack test coverage", it may make sense
> to add a test taken from Peff's earlier response to increase test
> coverage, perhaps?
In addition to adding more tests to t/t1091-sparse-checkout-builtin.sh
to cover these duplicate cases. To demonstrate your quadratic perf
improvement, a test in t/perf/p2000-sparse-operations.sh or similar
would be good to add.
I expect that the test you would add doesn't matter too much about
the data shape, but would look very different from most tests in
p2000. You can make use of the constructed repo's directory structure
that has nesting directories with name f1, f2, f3, or f4.
Here's something to get you started that I haven't tested myself:
test_perf 'duplicate sparse directories' '
(
cd full-v4 &&
for i in $(test_seq 1000)
do
printf "f1/f2/f3/f4\n"
done >in &&
git sparse-checkout set --stdin <in
)
'
That should test the logic with 1000 identical directories, which
should be enough to have the quadratic growth show up.
Thanks,
-Stolee
next prev parent reply other threads:[~2026-01-18 2:46 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-14 19:28 [PATCH] sparse-checkout: optimize string_list construction amisha
2026-01-14 21:35 ` Jeff King
2026-01-18 2:39 ` Derrick Stolee
2026-01-15 12:56 ` [PATCH v2] " amisha
2026-01-15 13:09 ` [PATCH v3] " amisha
2026-01-15 13:15 ` Amisha Chhajed
2026-01-15 20:09 ` Jeff King
2026-01-16 17:03 ` Amisha Chhajed
2026-01-15 22:26 ` René Scharfe
2026-01-16 8:30 ` Amisha Chhajed
2026-01-16 17:17 ` Junio C Hamano
2026-01-18 2:46 ` Derrick Stolee [this message]
2026-01-18 13:09 ` Amisha Chhajed
2026-01-15 13:55 ` Junio C Hamano
2026-01-16 16:50 ` [PATCH] " amisha
2026-01-16 19:11 ` Junio C Hamano
2026-01-18 13:07 ` Amisha Chhajed
2026-01-19 5:32 ` Jeff King
2026-01-19 19:06 ` Junio C Hamano
2026-01-19 12:33 ` [PATCH v5 1/2] " amisha
2026-01-19 17:04 ` Derrick Stolee
2026-01-19 18:33 ` Pushkar Singh
2026-01-20 15:47 ` Amisha Chhajed
2026-01-20 15:38 ` [PATCH v6] sparse-checkout: optimize string_list construction and add tests to verify deduplication amisha
2026-01-20 20:37 ` Derrick Stolee
2026-01-21 13:00 ` [PATCH v7] " Amisha Chhajed
2026-01-21 16:28 ` Derrick Stolee
2026-01-21 16:51 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c5631f7d-72ff-4876-9b68-ea4a70fde501@gmail.com \
--to=stolee@gmail.com \
--cc=amishhhaaaa@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=l.s.r@web.de \
--cc=newren@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox