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

From: Luca Milanesio <luca.milanesio@gmail.com>
Date: Oct 14, 2024, 20:33 UTC
Message-ID: <569E3AEA-AC68-4186-B38C-2E47DAB9890E@gmail.com>
In-Reply-To: <LV8PR12MB9407CB282D1FD4998C659D29C2442@LV8PR12MB9407.namprd12.prod.outlook.com>

> On 14 Oct 2024, at 21:07, Martin Fick <mfick@nvidia.com> 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.