What Filtering Strategies RTK Employs for Common Git Commands

RTK applies lightweight, command-specific filters before displaying output, reducing token counts by 60-90% while keeping startup times under 10 milliseconds.

RTK (Rust Token Killer) wraps the most frequently used git sub-commands to minimize token overhead in LLM workflows. According to the rtk-ai/rtk source code, the tool intercepts and transforms raw git output through specialized filtering logic defined in src/cmds/git/git.rs. Each major command receives tailored processing designed to preserve essential information while eliminating noise.

How RTK Filters Git Diff Output

RTK handles git diff through a two-stage process defined in the run_diff function (lines 20-48). First, it executes git diff --stat to provide a one-line summary of changed files. Then it runs the full diff and passes the result through compact_diff (lines 89-96), truncating output to a default maximum of 500 lines.

The compact_diff primitive, located in src/core/utils.rs, removes unchanged context lines and shortens long lines to save tokens. However, if the user supplies --stat, --numstat, --shortstat, or explicitly adds --no-compact, RTK skips the compacting step and streams raw output instead. This ensures compatibility with scripts expecting standard git formatting while defaulting to a concise view.

Git Log Filtering and Format Injection

For git log, RTK injects a custom pretty format (%h %s (%ar) <%an>\n%b\n---END---) when users do not provide --oneline, --pretty, or --format flags. The run_log function (lines 15-58) also adds --no-merges by default unless explicitly requested, and limits commits to 10 by default or 50 when using compact formatting.

After execution, the filter_log_output helper (lines 39-66) post-processes the stream to truncate long lines to 80 characters (120 when users set custom limits) and retains up to three body lines per commit. When users specify their own format flags, RTK respects the custom formatting and only applies the user-provided limit (defaulting to 50 for --oneline), without injecting its own template.

Status Output Simplification Strategies

RTK processes git status differently depending on whether flags are present. By default, run_status (lines 69-94) executes git status --porcelain -b to get machine-readable output, then transforms it via format_status_output (lines 28-33) into a concise, color-free summary showing branch state and file status.

When users supply custom flags, RTK runs the exact command (git status <args>) and applies minimal filtering through filter_status_with_args (lines 32-66). This helper strips empty lines, removes git hints (such as "use 'git ...'"), and collapses a clean working tree into a single "clean — nothing to commit" line. This approach preserves porcelain compatibility while eliminating visual clutter.

Add, Commit, and Push Summaries

RTK provides lightweight feedback for write operations through targeted post-execution summaries. After git add, the run_add function (lines 38-80) executes git diff --cached --stat --shortstat to generate a one-line summary of staged changes, reducing output to "ok (nothing to add)" or "ok ".

For commits, run_commit (lines 11-46) extracts the new commit hash from the first line of stdout and returns a short "ok " message, or simply "ok" if hash extraction fails. During pushes, run_push (lines 72-110) parses stderr for standard git messages, returning "ok (up-to-date)" when current or "ok " when successfully pushed, based on parsing the -> line in the output.

Core Filtering Primitives in RTK

All git commands in RTK share a common foundation of lightweight filtering utilities designed to minimize processing overhead:

• compact_diff – Removes unchanged context lines and truncates long lines for diff output.
• filter_log_output – Handles line-wise truncation, user format detection, and boilerplate trailer omission.
• filter_status_with_args – Strips empty lines and help hints while condensing status messages.
• format_status_output – Converts porcelain format into human-readable summaries like "On branch main ahead 1".

These primitives operate synchronously without async overhead, ensuring the tool maintains its sub-10ms startup target while still achieving significant token savings. All commands also integrate with tracking::TimedExecution from src/core/tracking.rs, which records raw commands, filtered outputs, and timing statistics for later analysis via rtk gain.

Summary

• RTK applies command-specific filters before displaying output, with distinct logic for diff, log, status, add, commit, and push operations.
• Git diff uses a two-stage process with compact_diff to truncate to 500 lines by default, bypassable via --no-compact or stat flags.
• Git log injects custom pretty formats and post-processes with filter_log_output to limit line length and commit body depth.
• Git status switches between porcelain formatting for defaults and minimal filtering (filter_status_with_args) when custom flags are present.
• Write operations (add, commit, push) return one-line summaries extracted from git's standard output and error streams.
• All filtering is implemented in src/cmds/git/git.rs with utilities in src/core/utils.rs, maintaining startup times under 10ms while reducing tokens by 60-90%.

Frequently Asked Questions

How does RTK decide when to compact diff output?

RTK checks for the presence of --stat, --numstat, --shortstat, or --no-compact flags in the user arguments. If any are present, the run_diff function streams raw output without calling compact_diff. Otherwise, it truncates output to 500 lines and removes unchanged context lines.

What happens to git log output when I specify my own format?

When you provide --oneline, --pretty, or --format flags, RTK does not inject its custom template. The run_log function respects your specified format and only applies the truncation width of 120 characters rather than the default 80, along with any user-provided limit flags.

Why does RTK use git status --porcelain by default?

RTK uses git status --porcelain -b to obtain machine-readable output that format_status_output can reliably parse into a concise summary. This approach eliminates color codes and decorative text while preserving exact file states, making the output both token-efficient and deterministic for downstream processing.

Where does RTK store the raw versus filtered output for analysis?

The tracking::TimedExecution layer in src/core/tracking.rs captures both the raw git command and the RTK-filtered output, along with execution timing. This data feeds into the rtk gain analytics command, allowing users to quantify token savings across their workflow.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}