Thread (19 messages) 19 messages, 4 authors, 2026-01-16

Re: Slow git pack-refs --all

From: brian m. carlson <hidden>
Date: 2025-12-26 17:15:34

On 2025-12-26 at 04:45:07, Jeff King wrote:
On Thu, Dec 25, 2025 at 11:38:30PM +0000, brian m. carlson wrote:
quoted
I think this is from `should_pack_ref`:

    /* Do not pack broken refs: */
    if (!ref_resolves_to_object(ref->name, refs->base.repo, ref->oid, ref->flags))
    	return 0;

So Git is going to need to verify that the object at least exists.  I
don't know why we would need to _open_ them, however.  Perhaps someone
else has ideas.
The packed-refs file stores tag-peeling information. So pack-refs opens
the object for any newly written ref via peel_object(), which has to at
least read the header to get the type. That call happens via
write_with_updates() in packed-backend.c.

  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.

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.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help