pub struct FileEntry {
pub path: String,
pub disposition: Disposition,
pub mode: Option<String>,
pub old_mode: Option<String>,
pub old_path: Option<String>,
pub new_path: Option<String>,
pub rename_similarity: Option<u8>,
pub binary: bool,
pub submodule: Option<SubmoduleChange>,
pub generated: bool,
pub generated_by: Option<GeneratedBy>,
pub hunk_ids: Vec<String>,
}Expand description
One changed file in the canonical (--no-renames) view. A rename therefore
appears as a D entry plus an A entry; the rename-detected view annotates both.
Fields§
§path: String§disposition: Disposition§mode: Option<String>New-side mode (“100644”, “100755”, “120000”, “160000”); None on deletion.
old_mode: Option<String>Old-side mode when it differs from mode, and on deletion.
old_path: Option<String>On the A side of a detected rename: where the content came from.
new_path: Option<String>On the D side of a detected rename: where the content went. Together with
old_path this makes “moved and modified” addressable from both ends.
rename_similarity: Option<u8>Similarity score 0-100 from git’s rename detection. Present on both sides of a detected rename. Below ~95 the change is a modification, not a relocation, and must never be treated as skim-eligible.
binary: boolBinary files carry zero hunks; content is tracked by object id only.
submodule: Option<SubmoduleChange>§generated: boolHint for the noise tier. Computed (builtin list, gitattributes, repo config), never claimed by a model.
generated_by: Option<GeneratedBy>§hunk_ids: Vec<String>Ids into hunks, in file order.