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

[Jeff King <peff@peff.net>]

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.

> [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