Subject: Re: Slow git pack-refs --all

From: Jeff King <[email-masked]>
Date: Sat, 27 Dec 2025 02:36:34 -0500

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

> >   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