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

From: Jeff King <peff@peff.net>
Date: May 9, 2026, 17:53 UTC
Message-ID: <20260509175321.GA2336838@coredump.intra.peff.net>
In-Reply-To: <CAHYJk3R-TyYv1MizKmHhhADrQd+VnQjxSikpcaPLB=VfHrAwpg@mail.gmail.com>

On Sat, May 09, 2026 at 05:13:17PM +0200, Mikael Magnusson wrote:

Show 13 quoted lines

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

This is not the time-based maintenance runs, but rather an "auto" mode that is triggered by commands like commit when the repo state looks like it is in need. That mode has existed for many years, but used to be "git gc --auto". And now it is "git maintenance run --auto" with a new name and new code (and, it turns out, some new bugs).

The locking issue seems to be specific to --detach mode, so I don't think affects time-based runs, only the auto mode (though if you register for time-based maintenance and then manually run git-repack outside of "git maintenance run", I suspect you are subject to an unlikely race there).

I think this did get much worse in v2.54. I left more details elsewhere in the thread.

-Peff