Skip to main content

Module file

Module file 

Source
Expand description

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.

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§

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.