From: Karthik Nayak Date: Mon, 23 Feb 2026 09:14:20 GMT Subject: Re: [PATCH 00/17] refs: unify `refs_for_each_*()` functions Message-ID: In-Reply-To: <20260220-pks-refs-for-each-unification-v1-0-17170bd99de1@pks.im> Patrick Steinhardt writes: > Hi, > > we currently have 14 different `refs_for_each_*()` functions, with each > of them doing slightly different things. This makes for a confusing API > surface, and because the API is not built for extension we have to add a > new function every now and then to handle another esoteric edge case > that will ultimately only have at most a handful of callers. > > This design isn't really sensible in my opinion, and this patch series > aims to fix that. Instead of having a dozen different functions, it > introduces a new `refs_for_each_ref_ext()` function that simply takes an > options structure as input. From thereon, callers can mix and match the > parameters that they care about. > > The patch series is structured like this: > > - Patches 1 to 5 introduce some preliminary cleanups. > > - Patches 6 to 9 introduce `refs_for_each_ref_ext()` and move > more functionality into it. This also fixes a performance bug that > we have in one of the implementations. > > - Patch 10 adds some more verification for options that would have > caught the bugs in ps/for-each-ref-in-fixes. > > - The remaining patches drop 7 out of 14 functions and replace them > with `refs_for_each_ref_ext()`. It results in a bit of churn, so > while I think this churn is worth it, I consider these patches to be > optional. > > The patch series is built on top of 73fd77805f (The 5th batch, > 2026-02-17) with ps/for-each-ref-in-fixes at 6375a00ef1 (bisect: > simplify string_list memory handling, 2026-02-19) merged into it. > > Thanks! > > Patrick > I'm really happy with the patches, I have some small nits/questions, but it looks good otherwise. Thanks, Karthik [snip]