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

[Patrick Steinhardt <ps@pks.im>]

On Tue, Oct 15, 2024 at 12:52:12PM +0100, Luca Milanesio wrote:
> 
> 
> > 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 already have those, see "repack.updateServerInfo" and
"receive.updateServerInfo". Not quite a single kill switch, but it is
possible :)

Patrick