Module candidate_batch 

Pure framing of one git cat-file --batch reply. What: Read one git cat-file --batch reply from a byte stream, with no process involved. Why: Object bytes are untrusted input that may contain anything, including text that looks like a reply header. The reply is therefore framed only by the header’s declared size, never by searching content, and every malformed shape is a typed failure instead of a guess.

Git 2.56.0 (Documentation/git-cat-file.adoc, “BATCH OUTPUT”) prints, per request line: <oid> SP <type> SP <size> LF <contents> LF, or <request> SP missing LF.

In TS you’d write (pseudocode):

// const header = await readLine(stream); const body = await readExactly(stream, size);

Enums

BatchReply

What: What Git answered for one request line. Vec<u8> is an owned byte list (sibling String would require UTF-8). Why: File content is arbitrary bytes and must be kept exactly; a missing object is an ordinary answer the caller decides about.

ObjectKind

What: The four object types Git stores. Why: A candidate’s bytes must come from a blob, and HEAD must resolve to a commit; the caller checks the type instead of assuming it.

Constants

MAX_BATCH_HEADER_BYTES

What: The longest reply header accepted, in bytes, excluding its line feed. usize is the unsigned integer every length uses (siblings u32, u64). Why: A real header is at most 64 name digits, a type word and a decimal size (under 100 bytes). Without a bound, a stream that never sends a line feed would be buffered without limit. usize matches .len().

Functions

read_batch_reply

What: Read one complete reply to request from stream. request is the exact request line that was sent, without its line feed. Why: Git echoes the request in a missing reply and prints the resolved name in a found reply. When the request is itself a complete object name, a found reply naming any other object means requests and replies are out of step, and its bytes are refused rather than attributed to the wrong object.