Module checkout_workers 

Whether the checkout of a new worktree may be given Git’s parallel checkout, and the option that does it. What: Whether the checkout of a new worktree may be given Git’s parallel checkout, and the option that does it. Why: Git’s checkout.workers defaults to one worker, and a checkout of twenty thousand files measured several times faster with checkout.workers=0 (one worker per logical CPU). The owner decided on 2026-11-03 “Pass only if unset”: a value the person set anywhere Git reads (a configuration file of any scope, GIT_CONFIG_*, GIT_CONFIG_PARAMETERS, a -c or --config-env they typed) is theirs and stands alone; only where nothing sets the key does the wrapper put -c checkout.workers=0 before the subcommand of its own checkout run. The files are read through the one configuration read the wrapper already makes, so no extra Git start is added.

In TS you’d write (pseudocode):

if (!workersSetAnywhere(args, env, configSnapshot)) args.splice(subcommandIndex, 0, '-c', 'checkout.workers=0');

Constants

KEY

The configuration key, in the canonical form Git lists it.

Functions

configured

What: Whether any entry of the configuration read has the key, in any scope. Why: The listing holds every file Git reads, in precedence order; one entry of any value is the person’s.

environment_sets

What: Whether the environment sets the key: a GIT_CONFIG_KEY_<n> variable naming it, or GIT_CONFIG_PARAMETERS mentioning it. Why: Git reads these after every file, so a value there is the person’s whatever the files say; the check is on the text, so a spelling the reader would decline is still found.

insert_parallel_checkout

What: Put -c checkout.workers=0 in front of the subcommand of the arguments. Why: Git takes -c only as a global option, before the subcommand, after the options the person and the wrapper put there.

is_fallback_checkout

What: Whether the arguments are the wrapper’s own checkout of a new worktree after a snapshot or clone attempt failed: reset --hard as the subcommand. Why: That run is the checkout the person’s git worktree add would have made, so it takes the same option; every other step of the ladder is a bookkeeping or difference step and stays as it is.

parallel_checkout_wanted

What: Whether the wrapper may give the checkout parallel workers: nothing the person typed, exported or configured sets the key. Why: A configuration that cannot be read leaves the answer unknown, and unknown means the person’s setting may exist, so nothing is added.

typed_before_subcommand

What: Whether a global option the person typed before the subcommand names the key: -c checkout.workers=<n>, -ccheckout.workers=<n> or --config-env=checkout.workers=<variable>. Why: A typed value is the person’s, and the options come before the subcommand, so reading the words up to it finds them all.