Skip to main content

Module worktree_clean_content

Module worktree_clean_content 

Source
Expand description

What: The decision, by content and without a Git process, whether a tracked file that its index entry’s stat data cannot vouch for (a racily clean entry, a stale stat) still equals the committed blob: hash the file as a blob and compare it with the entry’s object name, refusing where a content conversion could make the two differ. Why: Git settles those entries by hashing the file; stat data alone cannot tell a modified file from a copied or cloned one that kept the index’s old inode and times. The hash of the raw bytes is conclusive only when Git’s own conversion on the way into the index (filter, ident, working-tree-encoding, or a line-ending conversion that strips a carriage return) leaves the bytes alone, so a path such an attribute applies to, and a file with a carriage return, are refused with that reason instead of guessed. The file is read through a handle opened below the worktree root without following a link, its type and mode are judged on that handle, and its state is compared before and after the read, so the bytes that were hashed are the bytes of the one file that was judged.

In TS you’d write (pseudocode):

const judge = new ContentJudge({ root, gitDir, commonDir, environment, format });
judge.agrees({ directory, parents, name, entry, id, indexSeconds }); // throws the reason the file cannot be proven equal

Structs§

ContentJudge
What: Decides, one entry at a time, whether a file equals its committed blob by content. Why: The attributes files are read once, on the first entry that needs them, and the per-directory ones are cached.
ConversionEnvironment
What: The environment facts the content decision depends on: the configuration files Git reads and the system attributes file. Why: A control injects both, so a decision never depends on the machine it runs on.
Place
Where a tracked file is: the held directory that contains it, the names above it and its own name.
ReadSeams
The moments of a judgment at which a control changes the file under it.

Enums§

SystemAttributes
Where Git reads the system attributes file from, as far as it can be established.

Constants§

ATTRIBUTES_LIMIT
The largest attributes file read; Git ignores a larger one, which here is a refusal.
CONTENT_LIMIT
The largest file read into memory to be hashed; a larger one is refused with that reason.

Functions§

read_at_most
What: Everything reader yields, or nothing when it yields more than limit bytes; it is never asked for more than limit + 1. Why: A file can grow after its size was looked at; the bound is on the read, not on an earlier look.
system_attributes_from
What: Where the system attributes file is for a Git started with variables. Why: GIT_ATTR_NOSYSTEM is read as Git reads a boolean environment variable (empty is false); the file is where the executable says it is, never derived from the system configuration path, which GIT_CONFIG_SYSTEM moves alone.