Re: [GSoC][PATCH v3 1/9] refs: add a generic 'optimize' API

From: shejialuo <shejialuo@gmail.com>
Date: Sep 18, 2025, 10:44 UTC
Message-ID: <aMvigMLPeQE-n-o_@ArchLinux>
In-Reply-To: <20250918054704.544254-2-meetsoni3017@gmail.com>

On Thu, Sep 18, 2025 at 11:16:56AM +0530, Meet Soni wrote:

> Add a new generic refs_optimize() API function that dispatches to a
> backend-specific implementation via a new 'optimize' vtable method.
>

Should "API" be enough instead of using "API function"? However, I think we need to give the motivation.

Show 25 quoted lines

> This lays the architectural groundwork for different reference backends
> (like 'files' and 'reftable') to provide their own storage optimization
> logic, which will be called from a single, generic entry point.
> 
> Mentored-by: Patrick Steinhardt <ps@pks.im>
> Mentored-by: shejialuo <shejialuo@gmail.com>
> Signed-off-by: Meet Soni <meetsoni3017@gmail.com>
> ---
>  refs.c               | 7 +++++++
>  refs.h               | 6 ++++++
>  refs/refs-internal.h | 3 +++
>  3 files changed, 16 insertions(+)
> 
> diff --git a/refs.c b/refs.c
> index 4ff55cf24f..2ea6fd2218 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -2282,6 +2282,13 @@ int refs_pack_refs(struct ref_store *refs, struct pack_refs_opts *opts)
>  	return refs->be->pack_refs(refs, opts);
>  }
>  
> +int refs_optimize(struct ref_store *refs, struct pack_refs_opts *opts)
> +{
> +	if (!refs->be->optimize)
> +		return 0;

I don't think we need to check `refs->be->optimize`. Even though for some backends, we won't do any optimization, we should register this callback instead of assigning `NULL`.

> +	return refs->be->optimize(refs, opts);
> +}
> +

Thanks, Jialuo