From: Luca Milanesio Date: Mon, 14 Oct 2024 20:33:17 GMT Subject: Re: Should object repacking only update server-info for packs instead of doing it for refs? Message-ID: <569E3AEA-AC68-4186-B38C-2E47DAB9890E@gmail.com> In-Reply-To: > On 14 Oct 2024, at 21:07, Martin Fick wrote: > > I have been experimenting with trying to run git geometric repacking after every push on our servers I had the same sentiment when I studied how geometric repacking works. When we tried to do geometric repacking every 5 minutes on a busy repo, we ended up with a single pack file most of the time, which isn’t really what you would expect with a geometric progression. Running it after *every* push would make more sense, as Martin is experimenting. Please keep us posted on the results :-) > and have noticed that even a NOOP geometric repack takes approximately 30s on one of my large repositories. Further investigation determined that it was the update-server-info call that was taking that 30s, so running repacking with the -n instead only takes 6ms in this case! I dug a bit deeper and found that it was the update_info_refs() call that takes all the time. This seemed a bit off to me. Yes, it makes sense that would be slow, I have almost 2Mrefs, but I had to ask myself, why is this being done from git repack? I believe it should be done to update objects/info/packs > 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. Luca.