pub struct Tracked {
pub path: Vec<u8>,
pub id: Vec<u8>,
pub mode: u32,
pub intent_to_add: bool,
}Expand description
One tracked path, as the index records it.
Fields§
§path: Vec<u8>The path, spelled exactly as the index spells it.
id: Vec<u8>Object id of its cleaned content.
mode: u32The entry mode: 0o100644, 0o100755, 0o120000 for a symbolic link,
0o160000 for a submodule.
Carried rather than dropped, and the reason is not tidiness. Measured on
the build before it was: status --fix read a tracked symlink as
ordinary content — a symlink’s blob is its target string, which carries
no magic — followed it with fs::read, encrypted whatever it pointed at
and repointed the entry, leaving the mode at 0o120000. The next clone
got a symlink whose target was the first NUL of a ciphertext, and the
plaintext of a file no pattern declared was now a blob in the object
database. The history scan had the check all along and the two disagreed.
intent_to_add: boolWhether this is a git add -N placeholder rather than staged content.
Such an entry carries mode 100644 and the empty blob, so it reads as
“stored in the clear” and --fix used to repoint it — announcing a
repair that the next git commit did not make, because git still treats
the path as unstaged.
Implementations§
Source§impl Tracked
impl Tracked
Sourcepub fn is_regular_file(&self) -> bool
pub fn is_regular_file(&self) -> bool
Whether this entry is a regular file, the only kind git filters.
A symbolic link and a submodule gitlink both hold something that is not file content, so no declaration could ever have applied to them.
Sourcepub fn holds_content(&self) -> bool
pub fn holds_content(&self) -> bool
Whether this entry holds content the next commit would actually store.