Taylor Blau <me@xxxxxxxxxxxx> writes:
> 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.
>> > ...
>> 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.
> 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 ;-).
