Skip to main content

Module commit_transaction

Module commit_transaction 

Source
Expand description

The commit transaction in the incumbent’s order, up to the settled policies. What: The values every commit of the service route shares: the invocation, how it can stop, what it came to, the selection the command line makes, and the policy checks over the private index. Why: The preparation (service_prepare.rs) and the commit command (commit_command.rs) pass these between them. The transaction that once landed a commit itself, with its registry, recovery and replay, is gone: the resident service is the only writer of a commit (doc/planning/cli-git-resident-service.md, “Landing every command line”).

In TS you’d write (pseudocode):

const selection = decideSelection(region, conclusion);

Structs§

CommitInvocation
What: Everything the invocation fixes before the transaction starts. Why: The steps share one identity, one parsed commit region and one configuration; passing them together keeps a step from reading another invocation’s state.
Selection
What: The commit-region facts the transaction decides from, derived once. Why: The mode and the selection flags are read in several steps.
TransactionResult
What: What the transaction decided. Why: The command prints the events, runs the post-commit lifecycle for a landed commit, and exits with the code.

Enums§

TransactionStop
What: Why the transaction stopped without a policy result. Why: The incumbent’s boundary maps each to a different ending: Git’s own exit code with no wrapper text, a message with exit status 1, a finding with exit status 2, or a verbatim stop text.

Functions§

base_object
What: The recorded base as an object ID, or nothing for an unborn branch. Why: The candidate listing compares the private index with this commit.
decide_selection
What: Decide the selection facts of one commit invocation. Why: Invalid combinations reach native Git unchanged, so it rejects them.
failed
What: A transaction failure with the generic code. Why: Most unexpected failures are reported the same way.
private_checks
What: Rebuild the shipped checks over the private commit index: rule facts stay real, the candidates come from the private index against the recorded base. Why: The incumbent’s rules ask real Git about the real index, while the content policies read what the transaction corrects.
settled_passes
What: How many passes changed the state when the convergence settled; any other ending counts none. Why: The fix summary names the passes of a settled convergence only.
staged_at_base
What: The candidate request for the paths a private index changes against the recorded base. Why: The policies check exactly the paths the commit changes; each path is literal and rooted at the top level, so a name with glob characters or a directory below the current one still names one file.