On Thu, Feb 04, 2021 at 02:41:39PM -0800, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx>
> writes:
>
> > One of my quite common workflows is to see whether an ancient topic branch I
> > have lying about has made it into Git. Since my local commit OIDs have
> > nothing to do with the OIDs of the corresponding commits in git/git, my only
> > way is to fire up git range-diff ...upstream/master, but of course that
> > output contains way more commits than I care about.
> >
> > To help this use case, here is a patch series that teaches git range-diff
> > the --left-only and --right-only options in the end, restricting the output
> > to those commits and commit pairs that correspond to the commits in the
> > first and the second range, respectively.
>
> Makes sense.
I'd add an additional use-case, which is ignoring new commits from
upstream when displaying a range-diff in rerolled patch series.
Oftentimes I'll find that the automatically-prepared range diff that
'git format-patch --cover-letter --range-diff' generates will include
new commits from upstream, so these new options should help me ignore
those in the output.
As an aside: I am curious if I'm missing something when you say the
"only way" is to ask for a 'git range-diff ...@{u}'. IIUC what you're
describing, I often resort to using 'git cherry' for that exact thing.
But, I may not be quite understanding your use-case (and why git-cherry
doesn't do what you want already).
My latter question is purely for satisfying my own curiosity; I don't
have any problem with a '--{left,right}-only' option in range-diff. From
my quick read of the patches, it all looks pretty sane to me.
Thanks,
Taylor
