I’ve been using range-diff for a while now, but I’d been stuck with a long input method for arguments. Today I learned a shortcut.

Primer

Recall that git range-diff looks at the differences between two ranges: commonly, we pass the two ranges explicitly; or, we can pass a base and two tips to have the same effect as <base>..<tip1> <base>..<tip2>. The manual explaining this notation gives the following example: “after rebasing a branch my-topic, git range-diff my-topic@{u} my-topic@{1} my-topic would show the differences introduced by the rebase.” So I’ve been writing

g range-diff @{u} @{1} @

and similar variants for several months. I actually recently switched to push.default = current where my @{upstream} is the branch I want to pull from (often some version of origin/main or upstream/main) and Git provides (after I push) @{push} as the branch I’m pushing to (e.g., origin/topic). With this layout, I run

g range-diff @{u} @{push} @

(There is no abbreviation for @{push}, sadly.)

Symmetric diff

Now, I knew that git range-diff also accepts a three-dot symmetric difference notation, so

g range-diff <left>...<right>
    -- becomes -->
g range-diff <right>..<left> <left>..<right>

But in the past, especially prior to push.default = current, I had not found this terribly useful. I was probably holding it wrong.

Update 2025-03-17: In truth, this works better if I haven’t rebased over all of upstreams changes; if my branch point changes, the notation with an explict base is usually less noisy. Why? The symmetric diff causes git range-diff to also show all the new commits on my branch that are already upstream (those different between my old and new branch points). With an explicit base, computing the range-diff is faster and the output is simpler to digest.

Today, I write (before pushing)

g range-diff @{push}... | copy-range-diff

and all is well. Use git log [--oneline] --graph --boundary --left-right --cherry-mark @{push}... to get a feel for what ranges are being compared.

Categories: Blog