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

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> 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.

I do not have strong opinions between keeping "git pack-refs" and
adding "git refs optimize"; in other words, the UI exposed to
end-user is secondary, so if people prefer the latter, that is fine
by me.

I do care about how the code is structured, though.

Thanks.