Re: [GSoC][PATCH v2 0/5] Add refs optimize subcommand
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 8, 2025, 16:41 UTC
- Message-ID
- <xmqqfrcwyjzo.fsf@gitster.g>
- In-Reply-To
- <xmqq348xyr5b.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
Show 26 quoted lines
> 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.