Module maintenance_run 

Running automatic maintenance after a landing: the config read, then git maintenance run --auto. What: Running automatic maintenance after a landing: one git config read for the maintenance keys (or the commit’s configuration snapshot), then git maintenance run --auto --quiet, detached or not, in the real worktree. Its exit status is returned for the caller to ignore, as native Git does. Why: Every landing migrates its objects into one pack; without this step the pack count grows by one per commit and every later Git process searches every pack. Failures are logged and never fail the landed commit.

In TS you’d write (pseudocode):

await runAutoMaintenance({ gitPath, cwd, globalArgs });

Enums

AutoMaintenanceOutcome

What: What automatic maintenance did. Why: Configuration can turn it off, which is not an exit status; the caller distinguishes the two.

Functions

run_auto_maintenance

What: Run automatic maintenance in the real worktree with the caller’s global options, reading the maintenance keys by starting git config. Why: The read and the run happen in the same order the incumbent uses, so the decision and its effect agree on one configuration snapshot per read.

run_auto_maintenance_with

What: Run automatic maintenance, taking the maintenance keys from the commit’s configuration snapshot when it models them. Why: The snapshot was read when the commit began, so a configuration that changed during the commit is not seen (a hook that sets maintenance.auto is the example); a snapshot read with global options, or one holding a value it does not model, starts git config as before.