Re: [GSoC][PATCH v2 0/5] Add refs optimize subcommand

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 8, 2025, 14:07 UTC
Message-ID: <xmqq348xyr5b.fsf@gitster.g>
In-Reply-To: <20250906075147.1076656-1-meetsoni3017@gmail.com>

Meet Soni <meetsoni3017@gmail.com> writes:

> This series introduces `git refs optimize` as a modern replacement for
> `git pack-refs`, continuing the effort to consolidate commands
> under the `git refs` namespace.

Sorry, but I do not quite see the point of this change. Is it your goal to eventually remove "git pack-refs"?

I would very much understand if this were:

    "git pack-refs" is a command that is very specific to the files
    backend to optimize the way refs are stored in that backend.  It
    does not do anything to other backends.

    Introduce "git refs optimize" as the end-user facing front-end
    so that later different backends, including reftable backend,
    can define their own way to optimize the way refs are stored in
    them.  As the first step, switch on what backend is in use in
    the repository, and invoke "git pack-refs" if the repository
    uses the files backend.

And when framed this way, I am not sure it is a good direction forward to have pack-refs.[ch] top-level files. I have to wonder if the approach should be more along this line?

 - Define the "optimize" action in the refs API.  What it really
   means to "optimize" may differ from backend to backend.  There
   may be refs_optimize(struct ref_store *refs) API entry point.

 - Add the new action to the vtable for refs backends.  There may be
   no action defined for reftable backend for now, or you may find
   there already are reftable specific optimizations you want to
   trigger from there.

 - Figure out how this interacts with existing refs_pack_refs();
   most likely it as the backend specific option, should go away,
   and its implementation would move to the "optimize" action driven
   from the vtable for files backend.

Once it is done, you do not necessarily need "git refs optimize", but the "git pack-refs" could be the front-end to trigger the more generic "optimize" action. In other words, in a repository whose refs are stored in reftable, "git pack-refs" would cease to be a no-op but can perform optimizations suitable in that repository.

That way, users do not need to learn a new command, which may be also an advantage over what is being proposed here.

Thanks.