Show 44 quoted lines
> 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.
>
> Changes in v2:
> - Move the removal of `refs_for_each_include_root_ref()` to the
> beginning of the series to avoid some unnecessary churn.
> - Some commit message improvements.
> - Make the converted version of `refs_for_each_glob_ref_in()` fit into
> the new calling conventions a bit better. The function was still
> stripping the prefix unconditionally for example, which I've now
> changed.
> - Link to v1: https://lore.kernel.org/r/20260220-pks-refs-for-each-unification-v1-0-17170bd99de1@pks.im
>