Module candidate_attribute 

Which candidate paths have their text Git attribute unset, read from the state the candidates were listed from. What: Which candidate paths have their text Git attribute unset (-text, which the binary macro includes), resolved by git check-attr against the same state the candidates were listed from. Why: A path whose text attribute is unset declares that its exact bytes matter, as a fuzz seed’s trailing bytes do. The attribute lives in the package’s own .gitattributes, so it moves with the package, unlike a path list kept elsewhere. Staged and projected candidates are answered from the private index, so a .gitattributes staged by the same command applies to it and an unstaged worktree edit does not; landed and pushed candidates are answered from the tree of the commit they came from.

In TS you’d write (pseudocode):

// const unset = await attributes.textUnset([Buffer.from('seed/case')]);

Structs

CandidateAttributes

What: The resolver of the text attribute for one prepared set of candidates. It owns copies of the Git executable, the global options and the child environment, which already name the private index. Why: The policy asks lazily, after the prepared candidates were handed over, so the resolver cannot borrow the provider that prepared them.

Enums

AttributeSource

What: Where the attributes of the candidates are read from. Index is the private index the candidates were prepared on; Tree is one commit or tree for every candidate; PerPath names the commit or tree each path was first listed from. Why: Staged candidates are judged by what is staged. A landed commit is judged by its own tree, and a push lists several commits and trees, each of which is judged by itself.

Constants

ATTRIBUTE_CHUNK_SIZE

How many paths one git check-attr command names, as many as one pathspec command of the candidate layer.

Functions

parse_text_unset

What: Parse the -z output of git check-attr text for the paths asked about, and return the asked paths whose value is unset. asked holds the arguments given to Git (the top level and the path), paths the candidate pathnames in the same order. Why: Each record is three NUL-terminated fields, path, attribute name and value, in the order asked. Only the exact value unset preserves a file: set, auto, unspecified and any other value leave it checked. A record that does not match what was asked is an error, never a default to text or to binary.