Expand description
Running real Git for transaction,
recovery and landing work.
What:
Running real Git for transaction,
recovery and landing work:
captured output,
an
optional private index and object store,
extra or removed variables,
and bytes on
standard input.
Why:
Every transaction step asks Git a question or writes an object;
one runner keeps every
such start an argument array (never a shell string) carrying the wrapper’s child
environment overlay (lock PID injection),
as the incumbent’s runTransactionGit does.
In TS you’d write (pseudocode):
const { stdout } = await runTransactionGit({ gitPath, cwd, args, indexPath, input });Structs§
- GitContext
- What: The real Git executable and the variables every Git child receives. Why: Transaction code is handed this once and starts every Git through it.
- GitFailure
- What:
Why a Git start failed.
Why:
A start that could not happen and a Git that exited unsuccessfully are reported with
the command named,
as
CommitTransactionGitError. - GitOutput
- What: How one Git start ended and what it wrote. Why: Callers decide on the exit code and parse standard output as bytes.
- GitRequest
- What: One Git start: where it runs, its arguments after the global prefix, and its environment and input adjustments. Why: A builder keeps call sites short while every option stays explicit.
Functions§
- command_
text - What:
The arguments of a request as display text,
git <arguments>. Why: Failure messages name the command. - run_git
- What:
Run one request and capture its output,
whatever its exit code.
std::io::Result<GitOutput>is “the outcome, or why Git could not start”. Why: Callers that treat a non-zero exit as an answer (a conflict, a missing ref) read the code themselves. - run_
git_ checked - What: Run one request and require success; a start failure or a non-zero exit is a failure naming the command and quoting Git’s standard error. Why: Most transaction steps cannot continue without Git’s answer.