Conversation
Co-authored-by: Jean du Plessis <jeandp@gmail.com>
chore: sync the codebase after mergew
When user runs 'git log -1 --format='%H' HEAD' where HEAD is a merge commit, rtk was adding --no-merges which filtered out the merge commit itself and returned the second parent instead. This made 'git log -1' return wrong SHAs for merge commits. Fix: don't add --no-merges when user explicitly passes -n N or --max-count=N. When a user specifies an exact count they expect exactly that many commits, not filtered results. Also skip --no-merges if user already passed --merges or --no-merges explicitly. Fixes #2009.
fix: honor explicit -n N limit for git log on merge commits
|
gitbluf seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
feat(hook): add pi support
pszymkowiak
left a comment
pszymkowiak
left a comment
There was a problem hiding this comment.
Reviewed and tested on a fresh build of the PR head — good to merge. ✅
Quality gate: cargo fmt --check clean · cargo clippy --all-targets no issues · full suite 1928 passed / 0 failed.
Pi integration (#1741): verified install/uninstall on real commands — local + global (dry-run, real, idempotent), PI_CODING_AGENT_DIR override, old --pi flag correctly rejected in favor of --agent pi, installed rtk.ts byte-identical to source, and the TS extension's exit-code contract (3 = rewrite, 1 = passthrough, fail-open) matches rtk rewrite.
git log -n fix (#2015): rtk git log -n 8 now returns the exact same commits as raw git log -n 8, merges included, while the default rtk git log still strips merges (compaction preserved). -N, -n N, --max-count=N / --max-count N all honored.
Two non-blocking notes:
- Glued
-n5form isn't detected as a limit flag, so it still strips merges (pre-existing, uncommon — worth a follow-up). - The two-dot diff shows an apparent
0.41.0 → 0.40.0change, but it's a false alarm: develop never touched the version vs. merge-base, so the 3-way merge keeps0.41.0(release-please re-bumps post-merge).
Good to merge.
6 participants
Features
Fix