Subject: Re: [PATCH 6/9] list-objects-filter-options: support 'auto' mode for --filter

From: Patrick Steinhardt <[email-masked]>
Date: Wed, 7 Jan 2026 11:05:31 +0100

On Tue, Dec 23, 2025 at 12:11:10PM +0100, Christian Couder wrote:
> In a following commit, we are going to allow passing "auto" as a
> <filterspec> to the `--filter=<filterspec>` option, but only for some
> commands. Other commands that support the `--filter=<filterspec>`
> option should still die() when 'auto' is passed.

Okay. I assume the idea is that the user can eventually say `git clone
--filter=auto`, and Git would automatically pick the best filter
advertised by the remote. Sounds reasonable to me.

> Let's set up the "list-objects-filter-options.{c,h}" infrastructure to
> support that:
> 
> - Add a new `unsigned int allow_auto_filter : 1;` flag to
>   `struct list_objects_filter_options` which specifies if "auto" is
>   accepted or not.
> - Change gently_parse_list_objects_filter() to parse "auto" if it's
>   accepted.
> - Make sure we die() if "auto" is combined with another filter.
> - Update list_objects_filter_release() to preserve the
>   allow_auto_filter flag, as this function is often called (via
>   opt_parse_list_objects_filter) to reset the struct before parsing a
>   new value.
> 
> Let's also update `list-objects-filter.c` to recognize the new
> `LOFC_AUTO` choice. Since "auto" must be resolved to a concrete filter
> before filtering actually begins, initializing a filter with
> `LOFC_AUTO` is invalid and will trigger a BUG().
> 
> Note that ideally combining "auto" with "auto" could be allowed, but in
> practice, it's probably not worth the added code complexity. And if we
> really want it, nothing prevents us to allow it in future work.

I guess the question is what this would even mean, and I cannot think
of any benefit to allow `--filter=combine:auto+auto`. So agreed

> If we ever want to give a meaning to combining "auto" with a different
> filter too, nothing prevents us to do that in future work either.

So basically the case where the user knows that they definitely don't
want blobs, and in addition they want to pick the best filter advertised
by the server? Yeah, that sounds like it could eventually be a nice
addition.

> diff --git a/list-objects-filter-options.c b/list-objects-filter-options.c
> index 7420bf81fe..f13ae5caeb 100644
> --- a/list-objects-filter-options.c
> +++ b/list-objects-filter-options.c
> @@ -52,7 +54,17 @@ int gently_parse_list_objects_filter(
>  	if (filter_options->choice)
>  		BUG("filter_options already populated");
>  
> -	if (!strcmp(arg, "blob:none")) {
> +	if (!strcmp(arg, "auto")) {
> +		if (!filter_options->allow_auto_filter) {
> +			strbuf_addstr(
> +				errbuf,
> +				_("'auto' filter not supported by this command"));

Tiny nit: the indentation looks a bit weird here.

> @@ -146,10 +158,20 @@ static int parse_combine_subfilter(
>  
>  	decoded = url_percent_decode(subspec->buf);
>  
> -	result = has_reserved_character(subspec, errbuf) ||
> -		gently_parse_list_objects_filter(
> +	result = has_reserved_character(subspec, errbuf);
> +	if (result)
> +		goto cleanup;
> +
> +	result = gently_parse_list_objects_filter(
>  			&filter_options->sub[new_index], decoded, errbuf);
> +	if (result)
> +		goto cleanup;
> +
> +	result = (filter_options->sub[new_index].choice == LOFC_AUTO);
> +	if (result)
> +		strbuf_addstr(errbuf, _("an 'auto' filter cannot be combined"));

Nit: let's maybe also add the `goto cleanup` here. I'm not a fan of
leaving it away for the final statement as it makes it easy to forget
backfilling it in case this function needs to be extended in the future.

> @@ -317,6 +345,7 @@ void list_objects_filter_release(
>  	struct list_objects_filter_options *filter_options)
>  {
>  	size_t sub;
> +	unsigned int allow_auto_filter = filter_options->allow_auto_filter;
>  
>  	if (!filter_options)
>  		return;
> @@ -326,6 +355,7 @@ void list_objects_filter_release(
>  		list_objects_filter_release(&filter_options->sub[sub]);
>  	free(filter_options->sub);
>  	list_objects_filter_init(filter_options);
> +	filter_options->allow_auto_filter = allow_auto_filter;
>  }

Why do we do this extra step to restore the `allow_auto_filter` option
here? Are there any callers that reuse the filter after it has been
released?

In any case, this function does have clearing semantics as it also knows
to re-init the filter options. So it's somewhat misnamed and really
should be called `list_objects_filter_clear()` according to our coding
guidelines. That's certainly outside the scope of this patch series
though.

Patrick