Patrick Steinhardt <ps@xxxxxx> writes:
> [snip]
>
> ref-filter.c | 28 +++++++++++++++++++++-------
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/ref-filter.c b/ref-filter.c
> index dd195007ce1..424a9cb50ae 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -3244,10 +3244,31 @@ int filter_refs(struct ref_array *array, struct ref_filter *filter, unsigned int
> return ret;
> }
>
> +struct ref_sorting {
> + struct ref_sorting *next;
> + int atom; /* index into used_atom array (internal) */
> + enum ref_sorting_order sort_flags;
> +};
> +
> static inline int can_do_iterative_format(struct ref_filter *filter,
> struct ref_sorting *sorting,
> struct ref_format *format)
> {
> + /*
> + * Reference backends sort patterns lexicographically by refname, so if
> + * the sorting options ask for exactly that we are able to do iterative
> + * formatting.
> + *
> + * Note that we do not have to worry about multiple name patterns,
> + * either. Those get sorted and deduplicated eventually in
> + * `refs_for_each_fullref_in_prefixes()`, so we return names in the
> + * correct ordering here, too.
> + */
> + if (sorting && (sorting->next ||
> + sorting->sort_flags ||
> + used_atom[sorting->atom].atom_type != ATOM_REFNAME))
> + return 0;
> +
> /*
> * Filtering & formatting results within a single ref iteration
> * callback is not compatible with options that require
> @@ -3258,7 +3279,6 @@ static inline int can_do_iterative_format(struct ref_filter *filter,
> */
> return !(filter->reachable_from ||
> filter->unreachable_from ||
> - sorting ||
Just a small nit, because we remove `sorting` from this condition, I
suggest to also remove the following comment above it:
* - sorting the filtered results
Otherwise no comments from my side.
--
Toon
