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

From: Patrick Steinhardt <ps@pks.im>
Date: Oct 15, 2024, 11:02 UTC
Message-ID: <Zw5LwB2ap1QnmG6L@pks.im>
In-Reply-To: <Zw2MVqi0FLcMuR8Z@nand.local>

On Mon, Oct 14, 2024 at 05:25:42PM -0400, Taylor Blau wrote:

Show 15 quoted lines

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

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

Patrick