Re: [PATCH] packfile: fix perf regression with many packs

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]

Hi Ben,

On Wed, 12 Aug 2026, Ben Knoble wrote:

> > Le 12 août 2026 à 15:15, Johannes Schindelin via GitGitGadget
> > <gitgitgadget@gmail.com> a écrit :
> > 
> > [...]
> >    packfile: fix perf regression with many packs
> > 
> >    This issue was spotted by a Microsoft Git user with the massive
> >    amount of packfiles typical of an average, long-running monorepo
> >    checkout.
> 
> As a different kind of intermediate solution, would turning on
> maintenance for that user’s checkout help? (Not sure that would help CI
> clone times unless the server repacks, of course.)

I should have clarified that the issue is a _Scalar_ clone. And
specifically a _Microsoft Git Scalar_ clone.

This matters because, for various reasons that I don't want to elaborate
on because today I'm in need of lifting up my mood, a substantial part of
Microsoft Git failed to get upstreamed to core Git.

One of these is the "shared cache repository", i.e. a bare repository that
is established as an alternate of the actual clone, and into which the
actual scheduled fetches go. For full details, see
https://github.com/microsoft/git/commit/55226d12ed36 (scalar: do
initialize `gvfs.sharedCache`, 2021-05-03).

Now, maintenance _does_ run, usually, on that shared cache repository
(being careful not to inadvertently drop objects merely because they're
unreachable within the shared cache repository). So theoretically, you're
right that maintenance should help this issue.

For reasons (which I don't have the time to find out, but I suspect that
maintenance simply takes too long and does not finish by the time the
machine is shut down for the day), it is still not exactly rare to find
setups with five-digit packfile counts. And since we _can_ handle this
more gracefully, we should ;-)

Ciao,
Johannes