Subject: Re: [PATCH 3/8] pack-bitmap: reuse stored selected bitmaps

From: Jeff King <[email-masked]>
Date: Fri, 29 May 2026 02:00:42 -0400

On Wed, May 27, 2026 at 10:40:31AM -0400, Taylor Blau wrote:

> > > Teach `fill_bitmap_commit()` to notice that case. For non-root commits in
> > > the walk, look for a stored selected bitmap and OR it into the bitmap
> > > being built. If one exists, skip the commit, its tree, and its parents.
> >
> > I feel like this _shouldn't_ be necessary, because the idea of the
> > current writing code is to go from the roots up, following inverted
> > parent pointers, and passing the bitmap up as we go. So whenever we
> > visit a commit we should in theory have all of the ancestor's bits set
> > in that bitmap. But I remember that the simple-and-stupid approach ended
> > up being too memory hungry, so we pick some focal points in the graph
> > and then fill them independently.
> 
> It's sharing within the non-first parent history that is killing us
> here. I think what you said is true in a completely linear repository
> with no merges. But since we only pass commit masks from commits to
> their first parents, we don't reuse any already-generated bitmaps for
> common points in history not shared between commits' first parents.

Ah, that makes sense. I had forgotten exactly how the maximal-commit
selection worked, and what we compromised versus the original naive
"build from the bottom up" strategy.

> Yeah, these were for my own curiosity as much as anything. I had written
> them as a temporary measure in order to write the "[...] there are 1,261
> commits selected for bitmap coverage, and 1,382 maximal commits induced
> [...]" portion of the commit message above.
> 
> Once I had written it, I found the result useful enough to keep around.

Makes sense. It might help us (or even some very clueful user) debug or
fine-tune parameters down the road.

-Peff