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

Junio C Hamano [off-list ref] 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.