unexpected auto-maintenance, was Re: git hogs the CPU, RAM and storage despite its config

From: Jeff King <peff@peff.net>
Date: May 8, 2026, 18:03 UTC
Message-ID: <20260508180341.GB737125@coredump.intra.peff.net>
In-Reply-To: <CAKcFC3arsYExb5dCMQspo4V9UFDadFaj8Q4PUsMWZJw_eYrMzA@mail.gmail.com>

On Mon, May 04, 2026 at 05:27:21PM +0200, jean-christophe manciot wrote:

> [gc]
>     auto = 0

This is enough to disable auto-gc. But these days we also (instead?) run git-maintenance, which is controlled by maintenance.auto. So you probably are getting a bunch of background git-maintenance runs kicked off.

Show 6 quoted lines

> [pack]
>     threads = 1
>     windowMemory = 1g
> 
> I expected git to use maximum one thread for packing and I'm surprised
> it even tried to perform packing as gc.auto was disabled.

This should work to tell pack-objects to use only one thread, but that is one thread per invocation. And we were probably kicking off a ton of processes due to the background maintenance (and worse, they were all doing the same work redundantly and maybe even stepping on each others toes).

+cc Stolee for wisdom on all things git-maintenance.

Should maintenance.auto fall back to gc.auto for compatibility and avoiding unwanted surprises when people upgrade?

Also, should background maintenance be locking to avoid multiple runs? It does not seem to do so, and if I run:

  git init
  for i in $(seq 10000); do
    echo $i >>file
    git add file
    git commit -m "commit $i"
  done

I get several concurrent pack-objects processes. After a few thousand commits I got bored and hit ^C, and the resulting repo was corrupt! Which is not too surprising, as multiple simultaneous repacks are known to be unsafe, but means we should probably avoid them.

-Peff