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