Module candidate_tree 

The files of a commit’s tree with their modes and objects. What: Parse the NUL-delimited records of git ls-tree -r -z --full-tree <commit>: every file of one commit with its mode and object. Why: The dependent-version policy compares the candidate state with HEAD: it reads each workspace manifest’s HEAD bytes, and a direct fix may change a tracked file it did not select only when HEAD holds that file as the same ordinary blob. One listing answers both for every path. Pathnames stay the raw bytes Git printed.

Git 2.56.0 (builtin/ls-tree.c, show_tree_default) prints, with -r -z: <mode> SP <type> SP <object> TAB <path> NUL.

In TS you’d write (pseudocode):

// const records = parseTreeRecords(stdout); const head = new Map(records.map((r) => [r.path, r]));

Structs

TreeRecord

What: One file of a commit’s tree. #[derive(...)] generates cloning, debug printing and ==. Why: A record holds what a comparison with an index entry needs: mode and object.

Functions

parse_tree_records

What: Parse a complete git ls-tree -r -z listing. Result<Vec<TreeRecord>, CandidateError> is “every record, or the first failure”. Why: A listing that does not end with NUL was cut short; a partial list would read a file HEAD holds as new, so the whole listing is refused.