Re: [PATCH 00/17] refs: unify `refs_for_each_*()` functions

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