Skip to main content

Module rule_worktree_dirty

Module rule_worktree_dirty 

Source
Expand description

The query and reading of “does this worktree hold uncommitted state?”. What: The question “does this worktree hold uncommitted state?” as one Git query and its reading. Why: A command that can discard uncommitted state is judged by whether any exists: a clean linked worktree has nothing to lose, a dirty one does. Tracked changes (staged or not) always count; untracked files count only for the commands that delete them.

In TS you’d write (pseudocode):

// git status --porcelain=v1 --untracked-files=no  => dirty when it prints anything

Enums§

DirtyScope
What: Which files count as uncommitted state. An enum is a closed set of named alternatives. Why: A reset --hard loses tracked changes only, a clean loses untracked files only; asking for the wrong set would reject a harmless command or let a destructive one through.

Functions§

dirty_from_output
What: Read the query: any output line means uncommitted state exists. Result<bool, String> is “the answer, or why Git could not give one”. Why: A status that failed says nothing, and a safety check must not read a failure as “clean”.
dirty_query_arguments
What: The arguments of the status query, after the invocation’s global options. Vec<OsString> is an owned list of byte-preserving text. Why: --no-optional-locks keeps a read from writing the index, and the porcelain form is stable across Git versions.