Module config 

Reading and validating cli-git.config.jsonc and the Git configuration one invocation is judged by. What: Reading and validating cli-git.config.jsonc and the Git configuration one invocation is judged by. Why: Settings reach every other subsystem through these modules, so they are easy to find in one place.

In TS you’d write (pseudocode):

// config/index.ts: one `export * from './file'` per module below.

Modules

config_error

The one failure type for rejected configuration content or files. What: The one failure type for rejected cli-git.config.jsonc content or files. Why: Callers render a single configuration diagnostic without parsing message text.

config_file

Repository-root discovery and bounded reading of cli-git.config.jsonc. What: Find and read cli-git.config.jsonc at a repository root. Why: Configuration is one data file at one fixed place; legacy executable configuration is reported for migration and never read, run or silently ignored.

config_fsync

Git’s core.fsync value read into the components it flushes. What: Git’s core.fsync value read into the set of components it flushes, and the value that keeps every component of a set except the pack’s own. Why: Git flushes only the components core.fsync names, and the wrapper asks the same question for two writes it makes itself: whether the index it writes in process is flushed, and whether the pack that git fast-import writes for a landing is flushed. Read from Git 2.56.0 (environment.c, parse_fsync_components; write-or-die.h).

config_loading

Lazy configuration loading for known inspection versus mutation/ambiguous commands. What: Policy-configuration loading decisions before expensive policy initialization. Why: Known inspection forms keep the fast path; mutations, aliases and ambiguous options require configuration.

config_parse

Whole-document JSONC validation into typed settings. What: Turn cli-git.config.jsonc text into validated typed settings. Why: Every unknown key, wrong type or ambiguous duplicate is rejected before any policy or transaction reads a setting.

config_rules_file

The rulesFile option: a repository-relative name that stays inside the repository. What: The rulesFile option of security/forbidden-strings: which files in the repository hold the scanner’s private rules, each written relative to the repository’s top level. This module checks one path; config_policies.rs reads the string and array forms and calls it for each path. Why: The user decided on 2026-10-05 that configuration names the rules file first, then FORBIDDEN_STRINGS_RULES, then the default file. A configured name is checked when the configuration is read: it must stay inside the repository by its words alone, so a configuration cannot point the scanner at a file elsewhere on the machine. A name that is missing on disk is not a configuration error; loading the rules reports it when the policy runs.

config_schema

Typed settings and their defaults. What: The typed settings a validated cli-git.config.jsonc produces, with defaults. Why: The policy engine and transactions read plain typed values, never JSON.

config_snapshot

One git config --list read, parsed, and the lookups the commit path makes against it. What: One read of the whole Git configuration (git config --list -z --show-scope), parsed here, and the lookups the commit path makes against it instead of starting git config for each key. Why: Every git config start costs a process, and a wrapped commit asked Git the same configuration several times (core.hooksPath, the hook switches, the maintenance keys, the ref storage). Git lists entries in precedence order (system, global, local, worktree, then GIT_CONFIG_COUNT, GIT_CONFIG_PARAMETERS and -c values, all in the command scope), so the last entry of a key is the value git config --get prints. A lookup answers only when it can reproduce Git’s own answer exactly; any value it does not model (~ and %(prefix) paths, unit suffixes, hexadecimal, a bad boolean) is Lookup::Unhandled, and the caller starts Git for that key as before.

invocation_config

Configuration of the repository one invocation selects. What: Load the policy configuration of the worktree one invocation runs in, and render the events configuration loading can produce. Why: Both wrapped Git commands and git cli-git check/fix need the same answer: what does the cli-git.config.jsonc of the worktree Git reported say.