Skip to main content

Module child_environment

Module child_environment 

Source
Expand description

Variables added to every real-Git child: lock PID injection and the forward-target marker. What: The environment variables cli-git adds for every real Git it starts. Why: Native Git must write lock-owner PID files, and a wrapper must be able to notice that another wrapper selected it as “real Git”.

In TS you’d write (pseudocode):

// spawn(gitPath, args, { env: { ...process.env, ...childEnvironmentOverlay(process.env, gitPath) } });

Constants§

COUNT_VARIABLE
Git’s count variable for environment-supplied configuration.
FORWARD_TARGET_VARIABLE
What: The variable naming the executable this wrapper selected as real Git. Why: If the selected executable is itself a cli-git wrapper (for example another build that file identity cannot recognise), it finds its own path here and stops instead of forwarding back and forth forever.

Functions§

child_environment_overlay
What: Compute every variable cli-git sets for a real Git child: the lock PID injection plus the forward-target marker naming real_git. Why: Every Git the wrapper starts, forwarded or queried, gets the same additions; the rest of the caller’s environment is inherited unchanged.
environment_value
What: Look one variable up the way C’s getenv does: the first entry wins. &[(OsString, OsString)] borrows a list of name/value pairs. Option<OsString> is “an owned value or nothing”. Why: The overlay must read exactly what the Git child will read. Returning an owned copy keeps the function free of borrow bookkeeping for the caller.
environment_with_overlay
What: The complete environment of a Git child that is started with a cleared environment: the caller’s variables, with every name the overlay sets replaced by the overlay’s value. Why: The incumbent’s push coordination, push and manual-push probe inherit the whole process environment (HOME, PATH, SSH_AUTH_SOCK, the user’s GIT_* variables) plus the overlay, and a credential helper or transport needs them; the overlay alone would start Git with an almost empty environment.
lockfile_pid_overlay
What: Compute the variables that append core.lockfilePid=true to an environment’s numbered Git configuration. Vec<(OsString, OsString)> is an owned list of name/value pairs; it is empty when nothing must change. Why: Native Git then writes an owner PID file beside each lock it takes, which lock-ownership checks rely on. Numbered entries are read before GIT_CONFIG_PARAMETERS, so a caller’s explicit -c core.lockfilePid=false still wins. A count Git would reject, or a numbered entry Git would report as missing, is left untouched so Git reports the caller’s own mistake.
parse_config_count
What: Parse GIT_CONFIG_COUNT exactly as Git 2.56.0 config.c does with strtoul(env, &endp, 10) followed by its *endp and INT_MAX checks. Option<u64> is Some(count) when Git accepts the value, None when Git would report “bogus count” or “too many entries”. Why: The overlay must append after the entries Git will really read, and must leave a value Git rejects untouched so Git reports the caller’s own mistake. strtoul skips leading whitespace and accepts one sign; a negated nonzero value wraps above INT_MAX, so only -0 survives with a minus sign.