Module file 

One file’s whole content at a revision, as its lines.

The review page draws a diff’s bounded hunks, so the lines BETWEEN them are exactly what its record does not carry; expanding a gap needs the file itself, read at the revision the scope’s diff describes. git show <rev>:<path> is that read - the revision is a commit’s own tree for a commit scope, and the branch tip for the all-changes one.

The read is bounded by the caller’s ceiling and never by the file. Only a blob is a file (a gitlink’s size is the commit line git show prints for it), the size comes next (cat-file -s, a handful of bytes), and the content is read through a child killed at the ceiling - so a multi-gigabyte blob costs the ceiling’s allocation and not its own, and the content never goes through the layer’s own subprocess bound (STDOUT_SIZE_CAP, below the shipped ceiling), which is what keeps a file between that bound and the ceiling answering a flagged short read rather than a refusal. The LINES are bounded too (MAX_READ_LINES): a file of very short lines meets that long before either byte bound, and the answer’s own JSON is the other half of what a read costs.

A revision off the wire is resolved before it reaches git. git show reads a --output=<file>-shaped revision as an option of its own rather than as a revision, so an unvalidated one writes files wherever the caller says; resolve_commit is the one gate, and what comes back is a commit id - hex, never a dash - which every argv below interpolates.

Re-exports

use std::path::Path; 🔒

use std::time::Duration; 🔒

use tokio::io::AsyncReadExt as _; 🔒

use super::COMMAND_TIMEOUT; 🔒

use super::GitOutput; 🔒

use super::run_git_within; 🔒

Structs

FileLines

One file’s content at a revision, bounded by the caller’s ceiling.

Enums

FileReadRefusal

Why a file’s content could not be read at a revision, per child:

Constants

MAX_READ_LINES

The most lines one read carries, whatever ceiling the caller hands in: a file of very short lines meets this long before the byte ceiling, and every line past it is one the answer’s own JSON would pay for. The response is the smaller of the two bounds, flagged whenever either bites.

Functions

capped_lines 🔒

The file’s lines, cut to the counts a frame can afford.

file_size 🔒

The blob’s size in bytes, or None when git cannot read it.

is_blob 🔒

Whether the object at spec is a blob - the only kind this read calls a file.

merge_base

The commit base and HEAD forked at, as a validated commit id.

merge_base_within

merge_base with its command budget spelled. base goes through resolve_commit first, so only a commit id reaches the argv.

read_file_lines

Read path’s content in rev, as its lines, up to ceiling_bytes.

read_file_lines_within

read_file_lines with its command budget spelled; see the module’s sibling readers for why the budget bounds the machine, not git.

resolve_commit

The commit rev names, as its full id, or None when it names nothing git can read.

show_capped 🔒

git show <spec>, at most ceiling bytes of its stdout and never a byte more: the child is killed the moment the ceiling is reached, so what this allocates is the ceiling’s, not the file’s. None when the child could not start, the budget cut the read off, or it ended in failure - a git show that failed after the size probe answered is a read that did not happen, never an empty file.