[KuSh]

Summary

git 2.56 answers -h with its usage and exit 0; earlier releases exited 129. rtk git log took an exit code of 128 or more to mean git refused the walk, so on 2.56 rtk git log -hp ran the cap probe after the usage text, the probe got the usage again and read it as commits left over, and [rtk] capped at 10 commits; pass -n <count> for more was appended under git's usage.

A -h flag, alone or in a cluster, now counts as a walk that never ran. Only a flag token counts: --grep -h and -- -h still run the walk and still get the notice.

This is what turns a_clustered_h_is_answered_by_git_once red on the macOS and Windows runners that moved to git 2.56 (2.55 jobs still pass), so open PRs fail or pass depending on which runner image they land on.

Test plan

• New unit test a_short_h_asks_for_usage_but_a_value_or_pathspec_does_not; fails with the check disabled
• a_clustered_h_is_answered_by_git_once run against git 2.56.0 (alpine:edge): fails without the change with the same output as CI, passes with it
• cargo fmt --all --check, cargo clippy --all-targets, cargo test --all

🤖 Generated with Claude Code

[rtk-wshm-sync-bot]

wshm · Automated triage by AI

📊 Automated PR Analysis

🐛 Type	bug-fix
🟢 Risk	low

Summary

Fixes rtk git log incorrectly appending a cap notice when running on git 2.56+, where -h now exits 0 with usage text instead of the previous non-zero exit code. The fix detects a -h flag token (not a flag value or pathspec) and treats it as a walk that never ran, suppressing the spurious notice.

Review Checklist

• Tests present
• Breaking change
• Docs updated

---

Analyzed automatically by wshm · This is an automated analysis, not a human review.

[aeppling]

LGTM. Verified against develop on git 2.55 and 2.56: the false cap notice under -h usage is gone, no true notice is lost, and stdout and exit codes are unchanged.