Module manual_push_probe 

Authoritative manual-push updates discovered by a private dry-run push and confirmed with ls-remote. What: The authoritative ref updates a git push would send, discovered by a private dry-run push. Why: The manual-push policies must scan exactly what Git would publish, so the probe asks Git: a private pre-push hook in a private directory records the update lines Git negotiated (src/policy-engine/manual-push-hook.ts), and git ls-remote --refs confirms each destination value. A remote ref that changed between negotiation and confirmation stops the probe.

In TS you’d write (pseudocode):

const updates = await probeManualPushUpdates({ gitPath, cwd, args });

Structs

ManualPushProbeError

What: Why the probe could not establish the updates Git would push. Why: Every variant stops the policy lifecycle with a content-unavailable failure; none guesses an update.

ProbedUpdate

What: One update record a hook capture holds, before remote confirmation. Why: The advertised remote object is Git’s negotiated value; the confirmation must agree with it.

PushUpdate

What: One confirmed push update, the public fact the policies read. Why: An absent value is None, which replaces the incumbent’s ABSENT_GIT_VALUE sentinel.

Constants

CAPTURE_DIRECTORY_ENV

Environment variable naming the capture directory the hook writes to.

MAX_HOOK_INPUT_BYTES

Largest standard input the recording hook accepts, in bytes, as the incumbent’s hook does.

PRE_PUSH_FIELD_COUNT

Fields of one pre-push update record: local ref, local object, remote ref, remote object.

Functions

capture_probed_updates

What: Run the private dry-run push and read back the updates its hook captured. Why: Git may exit non-zero after the hook has captured the negotiated updates, so the captures decide, and an empty capture set is a probe failure.

confirm_group

What: Confirm one destination’s values with git ls-remote --refs and turn each probed update into a public update. Why: A destination that changed after negotiation would publish something the scan did not see, so a mismatch between negotiation and confirmation is an error, never a silent repair.

exceeds_capture_limit

What: Whether a capture holds more update text than the limit allows. Why: The hook reads one byte past the limit, so exactly the limit is complete input and one more byte is proof that input was cut short.

hook_source

What: The recording hook’s shell program: write the remote name and location, then the update lines, to a new capture file named by the hook’s process ID. Why: set -C makes the redirection exclusive, so two destinations never overwrite each other’s capture.

is_zero_oid

What: Whether a hexadecimal object name is the all-zero absence value.

parse_remote_refs

Parse git ls-remote --refs records into a ref-to-object map.

parse_update_records

What: Parse the hook’s standard input, one update per line. Why: Git guarantees four space-separated fields per update record; anything else stops the probe.

probe_arguments

What: The probe’s Git arguments: the invocation’s global options, the hook path override, then push with --dry-run --verify placed before any -- terminator. Why: The -- terminator is the user’s; the options Git interprets must stay before it.

probe_manual_push_updates

What: Discover the exact updates the push would send, confirmed against each destination. Why: The lifecycle’s candidates and published-set reads both start from these updates.