Module maintenance_decision 

Automatic maintenance decision: config record parsing and the enable and detach rules. What: The decision behind automatic maintenance after a landing: parsing git config --null --get-regexp records, and choosing whether git maintenance run --auto runs and whether it detaches. Why: Native git commit runs this step after updating HEAD; a landing replaces that commit with plumbing, so the pack count grows by one per commit unless this step runs. The rules mirror Git’s prepare_auto_maintenance in run-command.c, including JavaScript number semantics for values the incumbent reads with Number(...).

In TS you’d write (pseudocode):

const args = autoMaintenanceArgs(parseConfigRecords(output));

Enums

MaintenanceDecision

What: The arguments automatic maintenance runs, or the fact that configuration turned it off. Why: The incumbent’s disabled marker is a symbol; an enum keeps the two outcomes distinct without a sentinel value.

MaintenanceError

What: Why automatic maintenance could not be decided or run. Why: Each variant is a failure the caller can name; a start failure is kept as text so the error stays comparable in tests.

Constants

MAINTENANCE_CONFIG_PATTERN

The config key pattern the decision reads, as git config --get-regexp matches it. Keys are canonicalized as Git prints them.

Functions

auto_maintenance_arguments

What: The arguments native git commit would give git maintenance run, or Disabled when configuration turns automatic maintenance off. Why: maintenance.auto takes precedence over gc.auto; the detach setting follows the same precedence. Detaching is the default, as in Git.

parse_config_records

What: Parse git config --type=bool-or-int --null --get-regexp output into canonical key to value. A record without a newline is a key with no value, which Git reads as true. Why: Git prints one NUL-terminated record per key occurrence; the last occurrence wins, as Git’s single-value lookup does.