Re: [PATCH v2 00/17] pack-objects: add --path-walk option for better deltas
- From
Taylor Blau <me@ttaylorr.com>
- Date
- Oct 31, 2024, 21:07 UTC
- Message-ID
- <ZyPxprSncGa1CKep@nand.local>
- In-Reply-To
- <9aa2471b-0850-4707-9733-d3b33609f5f2@gmail.com>
On Wed, Oct 30, 2024 at 10:28:22PM -0400, Derrick Stolee wrote:
Show 26 quoted lines
> 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@gmail.com/ > > > > 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