Re: [PATCH v2 0/8] pack-objects: Create an alternative name hash algorithm (recreated)

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 4, 2024, 05:02 UTC
Message-ID: <xmqqldww3usp.fsf@gitster.g>
In-Reply-To: <b07c6b94-b1cc-4391-83fd-adc5bb5f92e3@gmail.com>

Derrick Stolee <stolee@gmail.com> writes:

Show 12 quoted lines

>> These do not sound like versions but more like variants to me,
>> especially if one is expected to perform better than another in some
>> cases and worse in some other cases.  Is it expected that JTan's hash
>> to perform better than the original and current hash in almost all
>> cases (I would not be surprised at all if that were the case)?
>
> There are some cases, such as the Linux kernel repo, that have slightly
> worse compression using JTan's hash. But the naming conventions in that
> repo are such that the v1 name hash was already pretty effective for
> that repo. The Git repository has similar issues. See Patch 5 for
> detailed analysis of these scenarios using the p5313-pack-objects.sh
> test script.

So it indeed is more "variant" than "version" where v(N+1) is almost always an implementation of a better idea than vN.

Show 5 quoted lines

> It may be possible to adapt some of the collision rate analysis from
> the test helper in Patch 6 to create a tool that recommends or
> dynamically selects the hash function that works best for the repo.
> Such a feature should be delayed until this code is exercised in more
> places.

Surely. But that is more advanced feature that can wait. It certainly has to wait until we have a foundation to use more than one variant safely, which this series lays a good foundation for.

Thanks.