Re: Could Git be smarter about object reuse?

From: Jeff King <peff@peff.net>
Date: Sep 23, 2025, 00:54 UTC
Message-ID: <20250923005421.GB2271307@coredump.intra.peff.net>
In-Reply-To: <ZURUr5sfXi0wsjBeXiwAxyNgalVa2ZveXDgoTcexUNOAgcP_JscHvFFDIss4stpsiB2MzUQ_Z30tFrPSgr8W8V02ecfCj4BFFwQqWwJpba4=@calamity.inc>

On Mon, Sep 22, 2025 at 10:09:41PM +0000, Sainan wrote:

Show 11 quoted lines

> > git repack -adb
> 
> Certainly got my fans spinning for a bit. :)
> 
> But I can indeed confirm that it does solve the issue at least when
> amending a commit (will need to do further testing and generally get a
> feel for it).
> 
> However, one issue that I'm immediately noticing is that if I do 'git
> pull', I get a new pack that is bitmap-less, once again likely
> exposing me to the same problems.

It should still work. The bitmap format is meant to degrade progressively. So if if you have a history like this:

   ROOT--...--A--B--C
               \
		D

and we have a bitmap for commit "B", then asking about "C" will let us traverse backwards until we hit "B", when we can fill in everything down to the root from the bitmap. We just have to traverse C's tree (but we can even avoid going into subtrees that are already mentioned in the bitmap).

For D it's a little trickier. We can't use the bitmap for B, but the idea is that we sprinkle them throughout history so that we'll eventually hit one and stop traversing.

So the big thing for making your case work is deciding whether we should use bitmaps at all. And if we have some already, then generally Git will try to use them, even if it means doing some fill-in traversal (because we really don't know how much fill-in traversal there will be ahead of time).

-Peff