rtk git log silently truncates output to 50 commits, ignoring --reverse and losing historical data
#1296 opened on Apr 14, 2026
Description
Description
When running rtk git log --all --oneline --format="%ci" --reverse, the output is silently truncated to 50 commits, starting from the most recent commits instead of the oldest ones. This behavior differs from native git log and causes data loss when users expect to see the full commit history in reverse order.
Steps to Reproduce
- Install rtk v0.35.0
- Run the following commands in a repository with 100+ commits:
Native git - shows all commits starting from the oldest (2022 in my case)
git log --all --oneline --format="%ci" --reverse | head -100
rtk git - only shows 50 commits, starting from recent ones (2025+)
rtk git log --all --oneline --format="%ci" --reverse | head -100
Expected Behavior
rtk git log --reverse should respect the --reverse flag and either:
- Return all commits in reverse order (oldest first), OR
- At least document the default limit clearly in help output
Actual Behavior │ Command │ Total Lines │ First Date │ │ git log --all --reverse │ 1045 │ 2022-01-10 │ │ rtk git log --all --reverse │ 50 │ 2025-09-26 │
The output is truncated to 50 commits before applying the reverse order, so --reverse becomes ineffective for viewing historical commits.
Workaround
Using -n parameter works to increase the limit:
rtk git log --all --oneline --format="%ci" --reverse -n 200
However, this is not intuitive and the default limit is not documented in rtk git log --help.
Environment
- rtk version: 0.35.0
- OS: macOS (Darwin 23.5.0)
- Shell: zsh
Suggested Improvements
- Document the default limit in rtk git log --help (e.g., "Default: 50 commits, use -n to override")
- Apply --reverse after truncation so that rtk git log --reverse shows the oldest N commits, not the newest N commits
- Consider warning users when output is truncated, similar to how grep warns about truncated results