Re: [PATCH 0/6] Optionally restrict range-diff output to "left" or "right" range only

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 5, 2021, 00:56 UTC
Message-ID: <xmqqtuqr2uz3.fsf@gitster.c.googlers.com>
In-Reply-To: <YBx5rmVsg1LJhSKN@nand.local>

Taylor Blau <me@ttaylorr.com> writes:

Show 19 quoted lines

> On Thu, Feb 04, 2021 at 02:41:39PM -0800, Junio C Hamano wrote:
>> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
>> 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.
>> > ...
>> 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.

Do you mean that the new round is based on an updated upstream commit, while the old series was based on a bit older upstream? After rebasing your topic, "range-diff @{1}..." would find the updates in the base (made in the upstream) plus the new round of your work on the right hand side of the symmetric range, while the left hand side solely consists of your old round (unless the upstream rewound their work, which should not happen). But that must not be it, I guess, because in such a case, among the commits in @{1}..HEAD, we cannot (eh, at least range-diff cannot) tell which one came from upstream and which one came from our fingers.

So I am a bit puzzled there.

Show 9 quoted lines

> 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.

The question is addressed to Dscho, and I am also somewhat curious. Perhaps the reason would be that the output from cherry is not as easy to read as range-diff, without any post-processing.

I do find "range-diff ...@{u}" a bit too blunt and heavy a hammer for that task, but as they say, when you are familiar with and fond of a hammer, all tasks look like nails ;-).