Re: [PATCH v3] [GSOC][RFC] format-patch: pass --left-only to range-diff

>
> "ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: ZheNing Hu <adlternative@gmail.com>
> >
> > In https://lore.kernel.org/git/YBx5rmVsg1LJhSKN@nand.local/,
> > Taylor Blau proposing `git format-patch --cover-letter
> > --range-diff` may mistakenly place upstream commit in the
> > range-diff output. Teach `format-patch` pass `--left-only`
> > to range-diff,can avoid this kind of mistake.
>
> The above is a bit too dense for average readers to grok.  Even if
> the readers refer to the external reference, it is unclear where the
> "may mistakenly" can come from and why "--left-only" would be
> useful (and our log message should not depend on external material
> so heavily to begin with).
>

> So let's think aloud to see what use case this may be helpful, and
> how the proposed solution makes the world a better place.
>
> If I understand correctly, the use case this tries to help is this:
>
>  * You had sent the v1 iteration of topic.  It was in the range
>    B1..T1 where B1 is the tip of the integration branch (like
>    'master') from the upstream.
>
>  * To prepare for the v2 iteration, not only you updated individual
>    commits, you rebased the series on a new upstream.  Now the topic
>    is in the range B2..T2, where B2 is the tip of the integration
>    branch from the upstream, and it is very likely that B2 is a
>    descendant of B1.
>
> And you want to find out how your commits in T2 (new iteration)
> compares with those in T1 (old iteration).  Normally,
>
>     $ git range-diff T1...T2
>
> would be the shortest-to-type and correct version but that is
> invalidated because you rebased.
>
>     ---o---B1--b---b---b---B2
>             \               \
>              t---t---T1      s---s---s---T2
>
> You'd have commits B1..T1 on the left hand side of the range-diff,
> while the right hand side has not just B2..T2 but also commits in
> the range B1..B2, too.
>
> By using --left-only (i.e. show only those pair that maps from
> commits in the left range), you can exclude the commits in the
> B1..B2.
>
>     $ git range-diff --left-only T1...T2
>
> I however wonder what --left-only (Suppress commits that are missing
> from the first range) would do to commits in range B2..T2 (they are
> all yours) that are (1) added since the v1 iteration, or (2)
> modified so drastically that no matching commit is found.  With the
> right invocation, of course,
>
>     $ git range-diff B1..T1 B2..T2
>
> you would not have such a problem.  If 2 't's in B1..T1 correspond
> to 2 of the 3 's's in B2..T2, at least the presense of the third 's'
> that did not match would show up in the output, making it clear that
> you have one more commit relative to the earlier iteration.  If use
> of --left-only filters it out, the output may be misleading to the
> readers, no?
>
> I started writing (or "thinking aloud") hoping that I can help
> coming up with a better log message to describe the problem being
> solved, but I ended up with "does this make the system better?"