> On 15 Oct 2024, at 12:02, Patrick Steinhardt <ps@xxxxxx> 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.
