On 27/05/2025 15:04, Patrick Steinhardt wrote: > Both git-gc(1) and git-maintenance(1) have logic to daemonize so that > the maintenance tasks are performed in the background. git-gc(1) has > some special logic though to not perform _all_ housekeeping tasks in the > background: both references and reflogs are still handled synchronously > ni the foreground. s/ni/in/ > > This split exists because otherwise it may easily happen that git-gc(1) > keeps for the "packed-refs" file locked for an extended amount of time, s/keeps for the/keeps the/ > where the next Git command that wants to modify any reference could now > fail. This was especially important in the past, where git-gc(1) was > still executed directly as part of our automatic maintenance: git-gc(1) > was invoked via `git gc --auto --detach`, so we knew to handle most of > the maintenance tasks in the background while doing those parts that may > cause locking issues in the foreground. > > We have since moved to git-maintenance(1), which is a more flexible > replacement for git-gc(1). By default this command runs git-gc(1), only, > but it can be configured to run different tasks, as well. This command > does not know about the split between maintenance tasks that should run > before and after detach though, and this has led to several bug reports > about spurious locking errors for the "packed-refs" file. > > Prepare for a fix by introducing this split for maintenance tasks. Note > that this commit does not yet change any of the tasks, so there should > not (yet) be a change in behaviour. > > Signed-off-by: Patrick Steinhardt <ps@xxxxxx> [snip] ATB, Ramsay Jones
