Summary

Stop injecting --no-merges. A cap trims the tail of a list; hiding merge commits removes
commits from the middle of history, and no truncation notice can express that. "Was the branch
merged?" has to stay answerable from git log.
Disclose RTK's own cap. run_log now asks git for one commit past the cap purely to detect
the overflow, and filter_log_output appends
[rtk] truncated at N commits; use -n N for more when it dropped anything.
An explicit -n N / --max-count is the agent's own choice and is never annotated.

Test plan

cargo fmt --all && cargo clippy --all-targets && cargo test
Manual testing: rtk <command> output inspected

Unit tests (added, TDD — red before green)

src/cmds/git/git.rs:

default_cap_is_disclosed — 12 commits, cap 10: still 10 entries, plus the marker.
default_cap_is_disclosed_for_user_formats — same for the --oneline/--pretty line path.
user_limit_is_not_annotated — an explicit limit is left alone.
exact_fit_is_not_annotated — nothing dropped, nothing claimed.

Two existing tests updated

test_filter_log_output_cap_lines and test_filter_log_output_user_format_with_limit asserted a
bare line count, which now includes the marker. Both were tightened to assert the commit count
and the presence of the disclosure — a stronger assertion than before.

Behavioural check on a real repo

16 commits, one of them a merge:

	Before	After
`rtk git log` — merge commit	absent	present
`rtk git log` — truncation marker	none	`[rtk] truncated at 10 commits; use -n N for more`
`rtk git log` — commits shown	10	10 (cap unchanged)
`rtk git log -n 20`	shows merge	shows merge, not annotated
`rtk git log --oneline`	shows merge	shows merge

Suite

cargo test --all: 2629 passed, 0 failed (2625 on develop, +4 from this PR).
cargo clippy --all-targets: clean. cargo fmt --all: clean.

With no explicit count run_log appended two flags of its own. -10 is a presentation cap but was emitted with no marker, so ten commits read as the whole history. --no-merges is not a cap at all: it removes commits from the middle of history, so 'was the branch merged?' -- asked by running git log -- got a confident no. Drop the --no-merges injection entirely, ask git for one commit past the cap so the overflow is detectable, and have filter_log_output append '[rtk] truncated at N commits; use -n N for more' when it dropped anything. An explicit -n is the agent's own choice and is left alone. The notice carries no number on purpose: the probe only proves more commits exist, not how many, and '+1 more' against a 16-commit history would swap one misleading output for another. search.rs already works this way -- it caps, then emits '+N more in <file>' with a tee hint. This applies the same rule to git log.

Copilot

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

Copilot AI lite review requested due to automatic review settings August 23, 2026 17:50

Copilot AI reviewed Aug 23, 2026

pszymkowiak mentioned this pull request Aug 23, 2026

rtk git log injects -10 --no-merges and never says so #3661

Open

Navigation Menu

Uh oh!

fix(git): stop hiding merge commits and disclose the default log cap - #3662