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

From: Mikael Magnusson <mikachu@gmail.com>
Date: May 9, 2026, 15:13 UTC
Message-ID: <CAHYJk3R-TyYv1MizKmHhhADrQd+VnQjxSikpcaPLB=VfHrAwpg@mail.gmail.com>
In-Reply-To: <20260508180341.GB737125@coredump.intra.peff.net>

On Fri, May 8, 2026 at 8:06 PM Jeff King <peff@peff.net> wrote:

Show 43 quoted lines

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

This sounds pretty horrific, this maintenance thing is enabled by default and there's nothing but pure chance that stops it from corrupting the repo if I happen to run git repack manually at the same time? It's hard to believe something this disruptive is even enabled by default, I don't expect jobs to kick off at random hours using up resources when I'm not working on git. (I'm assuming I'm several months late to protest this being enabled by default, but still). I would strongly suggest anything like this is *never* enabled by default, it is extremely surprising to find out about. Hopefully I misunderstood the part about this being enabled by default, and you still need to say "git maintenance register", right? (although the manpage erroneously(?) claims this will only enable tasks that are safe, which you seem to have disproven?). The documentation is extremely confusing to read, it says that registering a repo for maintenance will *disable* maintenance.auto in the current repo? It almost seems like you guys made two entirely separate things, named them both the same thing, and expected anyone to understand what's going on. git maintenance will schedule tasks to run in the background with cron, and if you don't do this, the config variable named "maintenance.auto" will control if things are repacked actively while doing things in the foreground? Holy moly. I'm leaving my confusion in place even though I figured it out because that is something else.

-- 
Mikael Magnusson