[AnayGarodia]

Closes #2940.

What

Adds a git ls-files handler that groups the tracked-file listing into per-directory counts instead of passing thousands of raw paths straight through.

Example on this repo (398 tracked files):

398 tracked files in 85 dirs:

src/filters/ 64
tests/fixtures/ 30
./ 23
src/cmds/system/ 17
...
+65 more dirs (129 files)

That's ~87% fewer tokens, well past the 60% bar.

Why

rtk discover flags git ls-files under TOP UNHANDLED COMMANDS. Agents run it to enumerate tracked paths, and in large repos the output is long and highly repetitive — the same shape find already compresses.

How

• New GitCommand::LsFiles handler in src/cmds/git/git.rs, registered in the clap GitCommands enum and the discover rule so the hook rewrites git ls-files → rtk git ls-files.
• group_ls_files collapses the listing to a total plus one dir/ count line per directory (most files first), capped with an overflow hint so nothing is lost. Directory grouping follows the existing find_cmd precedent. @inktomi confirmed this format on the issue.
• Flag-aware per the design philosophy: shape-changing flags (-z, -s/--stage, -t, -u, --debug, --eol, --error-unmatch, --format) pass through untouched, and small listings are returned unchanged. Guarded by never_worse, so output is never larger than raw.

Tests

Three unit tests in the git module using a real git ls-files fixture: directory grouping + >=60% savings, small-listing passthrough, and shape-flag detection. cargo fmt --all && cargo clippy --all-targets && cargo test --all all pass.

One open question: I sorted directories by file count (most first) rather than alphabetically, since the biggest directories are usually what the agent cares about. Easy to switch to alphabetical if you'd prefer it match find's ordering.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[CLAassistant]

All committers have signed the CLA.

[rtk-release-bot]

This pull request has been automatically marked as stale due to 90 days of inactivity. If this pull request is still relevant, please leave any comment (for example, "bump"), and we'll keep it open. Your contribution is very much appreciated — we're sorry we haven't been able to review it yet.

[KuSh]

Closing this as a duplicate of #1927, which adds the same git ls-files handler and was opened earlier. Both replace the path list with per-directory counts, and that is what #1927's review asks to change: #1927 (review)

Run on this branch at e391bfa, on rtk's own repo (798 tracked files), through rtk rewrite first as the hook does: git ls-files returns 23 lines of counts with no path in them, git ls-files src/filters returns src/filters/ 63 instead of 63 paths, and git ls-files | head -5 is rewritten to the handler and returns 5 counts. A single-path lookup such as git ls-files Cargo.toml comes back unchanged, which is right. A grouping that keeps every path, one line per directory followed by its file names, still saves 38% on the same 798 paths; #1927's review asks for that.

Your captured tests/fixtures/git_ls_files_raw.txt is pointed to there as a fixture #1927 can reuse, with credit to you. #2940 stays open until #1927 lands. Thank you for the work.