Re: Should object repacking only update server-info for packs instead of doing it for refs?

[Luca Milanesio <luca.milanesio@gmail.com>]

> On 15 Oct 2024, at 12:02, Patrick Steinhardt <ps@pks.im> wrote:
> 
> On Mon, Oct 14, 2024 at 05:25:42PM -0400, Taylor Blau wrote:
>> On Mon, Oct 14, 2024 at 09:33:17PM +0100, Luca Milanesio wrote:
>>>> It seems counterintuitive that an operation designed to repack
>>>> objects would be performing maintenance of any sort on refs?
>>> 
>>> True, it should not touch info/refs IMHO, as you’re really not
>>> changing any refs.
>> 
>> Right. I don't think that the current behavior is a bug, but just that
>> it's doing unnecessary work from within 'git repack' to update the
>> info/refs file when it's known ahead of time that the refs haven't
>> changed.
>> 
>> I think it's reasonable to skip this step when repacking, but of course
>> we would still want to update info/packs (assuming that the repack
>> wasn't a noop, of course).
> 
> It certainly may be reasonable. But in my opinion, it would be even more
> reasonable to not use the dumb HTTP transport at all. If you don't there
> is no reason to run git-update-server-info(1) in the first place, so
> you'd neither generate info/refs nor info/packs.

I don’t believe anyone uses it anymore, but someone *may* still use it, and therefore, Git should update the info/packs during geometric repacking.
However, why not introduce a “kill switch” in git config to disable it so that all tools can automatically skip the expensive info/packs (and info/refs) updates?

> We have been discussing in the past whether the dumb HTTP protocol
> should be deprecated, and in the context of that discussion we were also
> wondering whether we should start disabling git-update-server-info(1) by
> default.

+1 from me.

> Users don't generally need this, and most server operators
> don't need this nowadays, either. So why generate data that is useless
> in almost all cases?

Certainly not IMHO.

Luca.