Re: [PATCH] ref-filter: fix stale parsed objects

From: Jeff King <peff@peff.net>
Date: Nov 4, 2025, 22:04 UTC
Message-ID: <20251104220454.GC2618884@coredump.intra.peff.net>
In-Reply-To: <20251104211130.GA2618884@coredump.intra.peff.net>

On Tue, Nov 04, 2025 at 04:11:30PM -0500, Jeff King wrote:

Show 10 quoted lines

> I actually wonder if there is any other placeholder that benefits at
> all. The ref-filter code already tries to avoid doing unneeded work. The
> most obvious there is not loading the object at all, which is why stuff
> like "%(refname) %(objectname)" is faster than adding in %(raw), which
> needs the object contents (but no parsing). And likewise stuff like
> %(tag) needs parsing, and thus also triggers loading the object.
> 
> So 054f5f457e helps formats which require the object contents but _not_
> parsing. I can't think of another placeholder besides %(raw) which would
> benefit from that.

BTW, the one other oddity I aw while looking at this is %(describe). It asks for SOURCE_OBJ, which causes ref-filter to load the object. But we don't need it! We're just going to call out to git-describe.

But just changing that SOURCE_ flag is not enough, since we call grab_describe_values() from deep inside grab_values(), which we do after getting the object content. We'd have to move that call further up, but taking care to handle both deref=0 and deref=1 cases. Or maybe not? Does git-describe always return the same answer when describing a tag versus what it points to? In which case it should be more like how the AHEAD_BEHIND atom works.

At any rate, I was sufficiently grossed out by the ref-filter code that I stopped poking at it. Loading the objects is an unnecessary inefficiency, but compared to spawning a separate git-describe process, it is probably peanuts. So somebody who cares more can dig further if they want.

-Peff