feat: chezmoi dotfile manager support — and the chezmoi git gap

Summary

chezmoi is a dotfile manager that exposes a sizeable surface (diff, apply, status, managed, add, re-add, update, unmanaged, doctor, plus a git passthrough). Its outputs are good candidates for RTK filtering — large diffs, file lists grouped by directory, mixed source/target apply output.

Currently RTK has no chezmoi handling. PR #436 attempts to add it, but is stalled. This issue tracks the overall feature, including a gap that #436 does not address.

Local measurements

From rtk discover --all on a chezmoi-managed dotfiles workflow:

• chezmoi git … — 145 hits (commit + status + log against a dotfiles repo managed via chezmoi)
• chezmoi diff — 52 hits

Roughly 25K tokens saveable on those two alone, before considering apply / status / update.

Existing work — PR #436

PR #436 adds 9 subcommands: diff, apply, status, managed, add, re-add, update, unmanaged, doctor. Each with its own filter, claimed 70–90% savings, inline tests. Two blockers I can see today:

• CLA check still pending (license/cla = PENDING since 2026-03-20; the CLA bot's message suggests the author may have signed but the recheck never triggered)
• Mergeable state CONFLICTING — rebase needed after #826 reorganized src/; the author has not responded to the rebase notice from 2026-03-26

Worth surfacing this work and trying to land it before any re-implementation.

I checked discussions — no prior chezmoi thread exists. CONTRIBUTING.md suggests discussing core changes first, but since #436 already establishes prior art for chezmoi support, I'm filing this as an issue rather than a discussion. Can move it to discussions if maintainers prefer.

Gap not covered by #436 — chezmoi git

The rule in #436 explicitly excludes git:

r"^chezmoi\s+(diff|apply|status|managed|add|re-add|update|unmanaged|doctor)"

chezmoi git status, chezmoi git log, chezmoi git commit fall through to passthrough.

chezmoi git … invokes the git binary with chezmoi's source directory as cwd, so the output is plain git output — RTK's existing git filter could handle it.

Caveat — chezmoi git is not a candidate for command rewriting

#2077 shows why command-level rewriting via rewrite_prefixes breaks for working-directory wrappers: yadm uses --work-tree=$HOME plus a bare repo, so yadm status → rtk git status fails because plain git runs in $PWD where there is no .git.

chezmoi git has the same shape: git is invoked in chezmoi's source path, not the user's $PWD. Rewriting chezmoi git status → rtk git status would break the same way.

The pattern established by #2078 (keep src/filters/yadm.toml for output filtering only, drop yadm from rewrite_prefixes) is the right one: route chezmoi git <subcmd> through git's filter at the output layer, not at the routing layer.

Suggestion

Two complementary directions:

• Short term — add chezmoi git to a chezmoi handler (either as part of #436 or independently), routing output through git::run for known git subcommands and passthrough otherwise. Similar to how src/cmds/git/gt_cmd.rs handles gt (Graphite).
• Longer term — a configurable git-wrapper mechanism so yadm, chezmoi git, vcsh, etc. share the git pipeline instead of each carrying a partial copy. See discussion #2118.

Related

• #436 — feat(chezmoi): add chezmoi dotfile manager support
• #2077 — yadm working-directory wrapper trap
• #2078 — PR removing yadm from rewrite_prefixes, keeping output filter
• #2118 — discussion: configurable git-wrapper support

Environment

• rtk 0.42.0
• Windows 11 (Git Bash + PowerShell tool)