Junio C Hamano <gitster@xxxxxxxxx> 于2021年3月13日周六 上午6:51写道： > > "ZheNing Hu via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > From: ZheNing Hu <adlternative@xxxxxxxxx> > > > > 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). > You are right, commit information with the original thread link may make it difficult for readers to read. I will pay attention. > 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?" Junio, thank you for elaborating this issue in detail and clearly. I probably understand what you mean by "git range-diff B1..T1 B2..T2" to correctly output the commits on my two version topic branch, without including the upstream commits of B1..B2.So we don’t even need to specify the `--left-only` to avoid the output of B1...B2, right? The only thing I can think of now is that if users tend to use T1...T2 to compare the differences between the two topics, will the upstream commit in B1...B2 appear more abrupt? Thanks.
