Re: Slow git pack-refs --all

From: Jeff King <peff@peff.net>
Date: Dec 27, 2025, 07:36 UTC
Message-ID: <20251227073634.GA2071715@coredump.intra.peff.net>
In-Reply-To: <aU7Cs2pXiXInfBh4@fruit.crustytoothpaste.net>

On Fri, Dec 26, 2025 at 05:15:31PM +0000, brian m. carlson wrote:

Show 10 quoted lines

> >   If we wanted to be really pedantic, anything in refs/heads/ should not
> >   point to a non-commit and thus should never need to be peeled. I'm not
> >   sure if we want to embed that assumption in this code path, though
> >   (nor would it necessarily help Martin's case if the refs are not in
> >   refs/heads anyway).
> 
> I don't think that would be a good idea.  I know that people definitely
> do updates of the loose refs by hand (although they should not) and so
> it's entirely possible for them to contain invalid values, such as
> having branches contain non-commit objects.

Yeah, that matches my inclination.

> I wonder if reftable would avoid the need for this kind of expensive
> check since it would already have the data peeled if need be and
> wouldn't need to recompute the values.

It does the same amount of peeling, but it's amortized across more operations (i.e., whatever did those ref updates in the first place) rather than during the pack operation. And of course there really is no pack operation per se with reftables, but I believe it avoids re-peeling when rewriting entries during compaction.

It might actually do fewer object accesses overall if the ref-writing operations have already loaded the objects in question (and thus it knows whether they're tags or not, and may even have parsed tags in memory). It can also do more in some cases (e.g., two loose writes will peel for each write, whereas the files backend only bothers to peel during packing).

-Peff