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

quoted

  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