Module vcs 

VCS-state inspection helpers for kata apply --all (#80).

Phase 1 / 2 only ever clone template repos. Phase 3 added the ability to fan out apply across every registered project, which immediately raises the question: is each target PJ in a state where overwriting template-managed files is safe? An uncommitted edit could be silently clobbered, or the apply’s diff could be polluted with unrelated work-in-progress.

This module wraps the lightweight side of the answer:

• dirty_files runs git status --porcelain and returns the list of “user-dirty” paths — kata-owned bookkeeping files (.kata/applied.toml, .kata/vars*.toml) are filtered out so jj-colocated repos don’t get flagged as dirty every time git push moves the upstream pointer.

Detection limitation (out of scope for this iteration): jj workspaces that aren’t git-colocated are reported as non-git and therefore “clean by inference”. Almost every yukimemi/* PJ is colocated, so the git side is enough for the common case. A native jj backend can be slotted in later behind the same dirty_files signature.

Functions

commit_paths

Stage the given paths and create a commit with msg in dir. Returns Ok(false) when nothing was actually committed (every listed path was already in the index without changes — the usual case when the apply was a pure no-op), so callers can short-circuit the follow-up git push.

dirty_files

Inspect dir for uncommitted user work. Returns a list of relative paths the user has modified / added / removed, with kata-owned bookkeeping filtered out. Empty vec means clean.

pull_ff

Fast-forward dir’s current branch from its tracked remote (#94, the --pull half of the kata apply --all ergonomics). --ff-only is intentional: if local commits diverge from the remote, the consumer’s working state is in a shape kata shouldn’t try to auto-merge — surface the failure and let the per-PJ error path report it.

push_current

Push the current branch in dir to its tracked upstream. Ok(false) when no upstream is configured (the PJ is local-only) so the caller can log a warning instead of surfacing an error — matching pull_ff’s “missing-upstream is not a hard failure” stance.