Signal truncation in git diff, git log, and json filters

[FlorianBruniaux]

Problem

Three filters cut signal that LLMs need to function correctly:

1. git diff — max_hunk_lines = 30 (src/git.rs:281)

30 lines per hunk is too low for any meaningful refactor. Claude sees a truncated diff, assumes the change is complete, then produces incorrect code because it missed the rest of the hunk.

2. git log — 1 line of commit body (src/git.rs:492-493)

The filter keeps only the subject line and drops the body after the first non-empty line. This silently discards:

• BREAKING CHANGE: notes
• Migration instructions
• Co-author / fix references

Claude operating on release history or changelogs gets a misleading picture.

3. json — all values stripped (src/json_cmd.rs:86-173)

The JSON filter removes all values and shows only structure. For config debugging (the primary use case), this is useless — Claude needs to see both keys and values to spot a misconfiguration.

Proposed fixes

Filter	Current	Proposed
git diff hunk cap	30 lines	50-100 lines (configurable)
git log body	1 line	3 first non-empty lines
json values	stripped	preserved by default, opt-in --keys-only

Acceptance criteria

• rtk git diff shows hunks up to 100 lines before truncating
• rtk git log preserves BREAKING CHANGE and other body metadata
• rtk json shows values by default; --keys-only for structure-only view
• All three filters still achieve ≥50% savings vs raw output