# range-diff --matched-only draws suggestions to pick better inputs instead

_Reviewers say the noise from one-sided commits mostly comes from how range-diff is invoked, while Harald Nordgren wants an easy way to hide commits added by a rebase._

Section: Discussion. Edition of 2026-11-03. Written by an AI editor from the thread "[PATCH] range-diff: add --matched-only to skip one-sided commits" (23 messages): https://gitlist.dev/t/66310

Harald Nordgren's patch adds `--matched-only` to `git range-diff`. It sets both existing suppression flags, `--left-only` and `--right-only`, so that only commits that correspond between the two ranges are shown. It also extends the existing conflict check in show_range_diff() to reject combinations with other options.

Nordgren's motivation is that after he rebases a topic on the latest master, comparing the old and new versions with the symmetric-difference form makes him scroll through 311 unrelated commits before reaching what he changed.

Matt Hunter argued that the symmetric-difference form cannot tell new topic commits from commits that merely entered through a changed base, so it works only if history was rewritten in place on the same base. He suggested passing the base explicitly, for example `git range-diff origin/master <old> <new>`. Ben Knoble agreed that origin..old-topic and origin..new-topic would select only topic commits if both bases are reachable from origin.

Junio Hamano said he avoids rebasing topic branches without good reason, so that `git range-diff @{1}...` stays usable. He thought Nordgren's case was rebasing onto an updated base, where the three-argument form lacks a single suitable base. He also said a question AI review bots often miss is whether letting the options run at the same time makes sense at all.

Nordgren said that in this case `--left-only` solves it and that may be enough. He also repeated that he wants the unrelated commits gone. No decision has been made about the patch.