gix_status

Function index_as_worktree

source
pub fn index_as_worktree<'index, T, U, Find, E>(
    index: &'index State,
    worktree: &Path,
    collector: &mut impl VisitEntry<'index, ContentChange = T, SubmoduleStatus = U>,
    compare: impl CompareBlobs<Output = T> + Send + Clone,
    submodule: impl SubmoduleStatus<Output = U, Error = E> + Send + Clone,
    objects: Find,
    progress: &mut dyn Progress,
    _: Context<'_>,
    options: Options,
) -> Result<Outcome, Error>
where T: Send, U: Send, E: Error + Send + Sync + 'static, Find: Find + Send + Clone,
Expand description

Calculates the changes that need to be applied to an index to match the state of the worktree and makes them observable in collector, along with information produced by compare which gets to see blobs that may have changes, and submodule which can take a look at submodules in detail to produce status information (BASE version if its conflicting). options are used to configure the operation.

Note worktree must be the root path of the worktree, not a path inside of the worktree.

Note that index may require changes to be up-to-date with the working tree and avoid expensive computations by updating respective entries with stat information from the worktree, and its timestamp is adjusted to the current time for which it will be considered fresh. All changes that would be applied to the index are delegated to the caller, which receives these as EntryStatus. The pathspec is used to determine which index entries to check for status in the first place.

objects is used to access the version of an object in the object database for direct comparison.

It’s important to note that the index should have its timestamp updated with a timestamp from just before making this call if entries were updated

§Note

Technically, this function does more as it also provides additional information, like whether a file has conflicts, and files that were added with git add are shown as a special as well. It also provides updates to entry filesystem stats like git status would if it had to determine the hash. If that happened, the index should be written back after updating the entries with these updated stats, see Outcome::skipped.

Thus, some care has to be taken to do the right thing when letting the index match the worktree by evaluating the changes observed by the collector.