Derrick Stolee <stolee@xxxxxxxxx> writes: >> 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. > 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.
