rtk-ai/rtk

rtk git log silently truncates output to 50 commits, ignoring --reverse and losing historical data

Open

#1296 opened on Apr 14, 2026

View on GitHub
 (2 comments) (1 reaction) (0 assignees)Rust (48,085 stars) (2,914 forks)batch import
bugeffort-smallfilter-qualitygood first issue

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

  1. Install rtk v0.35.0
  2. 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:

  1. Return all commits in reverse order (oldest first), OR
  2. 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

  1. Document the default limit in rtk git log --help (e.g., "Default: 50 commits, use -n to override")
  2. Apply --reverse after truncation so that rtk git log --reverse shows the oldest N commits, not the newest N commits
  3. Consider warning users when output is truncated, similar to how grep warns about truncated results

Contributor guide