git commit: hook-rewritten output drops the [branch sha] line (cherry-pick unaffected)

[BigCactusLabs]

Summary

rtk's hook-rewriting of git commit strips the [branch <sha>] <message> line from output, losing the new commit's SHA. Other SHA-emitting operations (git cherry-pick) are unaffected, so the behavior appears to be commit-specific. The diff-stat line is also handled inconsistently — preserved on larger commits, dropped on smaller ones.

Environment

• rtk 0.40.0
• macOS Darwin 25.4.0 (arm64)
• zsh, Homebrew install (/opt/homebrew/bin/rtk)
• Invoked via Claude Code's bash hook (auto-rewrites git → rtk git)

Reproduction

tmp=$(mktemp -d) && cd "$tmp"
git init -q && git config user.email t@t && git config user.name t
echo a > a && git add a

# hook-rewritten path
git commit -m "first"
# → ok

echo b > b && git add b

# raw path via rtk proxy
rtk proxy git commit -m "second"
# → [main 77e5cc9] second
#    1 file changed, 1 insertion(+)
#    create mode 100644 b

Expected

Hook-rewritten output preserves the [branch <sha>] <message> line — that's the actionable result of the command. Token cost is ~10 chars for the SHA; information value is high (needed for any follow-up git show, PR description, revert, push-targeting, etc.).

Actual

Hook output is ok, with the SHA and (sometimes) the diff-stat dropped.

Inconsistency observed

Same hook path, two commits:

Commit	rtk output
4 files, +135/-39 (larger commit on a separate project)	ok 4 files changed, 135 insertions(+), 39 deletions(-)
1 file, +1 (this minimal repro)	ok

Diff-stat included in the first case, absent in the second. Either threshold-based or coincidental; either way, the SHA is missing from both.

Negative case (interesting)

git cherry-pick through the same hook returns the full [branch <sha>] <message> line — identical to rtk proxy raw output. So the SHA-stripping isn't a general output-rewriting rule; it's a commit-specific summarizer that doesn't realize the [branch <sha>] line is load-bearing.

Why it matters

The new commit SHA is the single most likely thing a caller needs from git commit output — to reference in a PR description, hand to git show, target a revert, push by SHA, or just confirm the commit landed where intended. An LLM caller (Claude Code) that has lost the SHA either has to fabricate one (82c9d27-ish is a real fabrication that just happened in my session) or run a follow-up git log -1 — which costs more tokens than just preserving the line would have.

Suggested fix

Preserve the [branch <sha>] <message> line verbatim. If the diff-stat is being summarized, keep the SHA line as a separate token-cheap header. Treat git commit output the same way git cherry-pick is already treated.