On Wed, Oct 30, 2024 at 10:28:22PM -0400, Derrick Stolee wrote: > On 10/29/24 2:02 PM, Taylor Blau wrote: > > On Mon, Oct 28, 2024 at 03:46:11PM -0400, Derrick Stolee wrote: > >> On 10/28/24 1:25 PM, Taylor Blau wrote: > >>> Unfortunately, there is no easy way to reuse the format of the existing > >>> hashcache extension as-is to indicate to the reader whether they are > >>> recording traditional name-hash values, or the new --path-walk hash > >>> values. > >> > >> The --path-walk option does not mess with the name-hash. You're thinking > >> of the --full-name-hash feature [1] that was pulled out due to a lack of > >> interest (and better results with --path-walk). > >> > >> [1] https://lore.kernel.org/git/pull.1785.git.1725890210.gitgitgadget@xxxxxxxxx/ > > > > Ah, gotcha. Thanks for clarifying. > > > > What is the incompatibility between the two, then? Is it just that > > bitmaps give us the objects in pack- or pseudo-pack order, and we don't > > have a way to permute that back into the order that --path-walk would > > give us? > > The incompatibility of reading bitmaps and using the path-walk API is > that the path-walk API does not check a bitmap to see if an object is > already discovered. Thus, it does not use the reachability information > from the bitmap at all and would parse commits and trees to find the > objects that should be in the pack-file. Sure, I think what I'm trying to understand here is whether this "incapability" is a fundamental one, or just that we haven't implemented checking bitmaps in the path-walk API yet. Thanks, Taylor
