Re: [PATCH v3] name-hash: don't add sparse directories in threaded lazy init
- From
Derrick Stolee <stolee@gmail.com>
- Date
- May 22, 2025, 01:48 UTC
- Message-ID
- <1ca297cc-35d8-4f8f-98d8-fc8d27cee2de@gmail.com>
- In-Reply-To
- <xmqqa5758wlk.fsf@gitster.g>
On 5/21/2025 5:47 PM, Junio C Hamano wrote:
Show 45 quoted lines
> "Alex Mironov via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> From: Alex Mironov <alexandrfox@gmail.com>
>>
>> Ensure that logic added in 5f11669586 (name-hash: don't add directories
>> to name_hash, 2021-04-12) also applies in multithreaded hashtable init
>> path.
>>
>> As per the original single-threaded change above: sparse directory entries
>> represent a directory that is outside the sparse-checkout definition.
>> These are not paths to blobs, so should not be added to the name_hash
>> table. Instead, they should be added to the directory hashtable when
>> 'ignore_case' is true.
>>
>> Add a condition to avoid placing sparse directories into the name_hash
>> hashtable. This avoids filling the table with extra entries that will
>> never be queried.
>>
>> Signed-off-by: Alex Mironov <alexandrfox@gmail.com>
>> ---
>
> Sounds quite sensible and the above reads better.
>
>> diff --git a/name-hash.c b/name-hash.c
>> index d66de1cdfd5..b91e2762678 100644
>> --- a/name-hash.c
>> +++ b/name-hash.c
>> @@ -492,8 +492,10 @@ static void *lazy_name_thread_proc(void *_data)
>> for (k = 0; k < d->istate->cache_nr; k++) {
>> struct cache_entry *ce_k = d->istate->cache[k];
>> ce_k->ce_flags |= CE_HASHED;
>> - hashmap_entry_init(&ce_k->ent, d->lazy_entries[k].hash_name);
>> - hashmap_add(&d->istate->name_hash, &ce_k->ent);
>> + if (!S_ISSPARSEDIR(ce_k->ce_mode)) {
>> + hashmap_entry_init(&ce_k->ent, d->lazy_entries[k].hash_name);
>> + hashmap_add(&d->istate->name_hash, &ce_k->ent);
>> + }
>> }
>
>
> This unfortunately gives us deeper nesting than your previous round,
> but the conditional matches the original commit and easier to see
> what is going on by comparing the uni- and multi-threaded variants.
>
> Nicely done. Will queue.I agree that this version is ready to go. Thanks for shepherding the v2 discussion.
-Stolee