Hi Uwe, On Fri, 22 Jan 2021, Uwe Kleine-König wrote: > On Thu, Jan 21, 2021 at 10:20:38PM +0000, Johannes Schindelin via GitGitGadget wrote: > > From: Johannes Schindelin <johannes.schindelin@xxxxxx> > > > > There are three forms, depending whether the user specifies one, two or > > three non-option arguments. We've never actually explained how this > > works in the manual, so let's explain it. > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > > --- > > Documentation/git-range-diff.txt | 13 +++++++++++++ > > 1 file changed, 13 insertions(+) > > > > diff --git a/Documentation/git-range-diff.txt b/Documentation/git-range-diff.txt > > index 9701c1e5fdd..76359baf26d 100644 > > --- a/Documentation/git-range-diff.txt > > +++ b/Documentation/git-range-diff.txt > > @@ -28,6 +28,19 @@ Finally, the list of matching commits is shown in the order of the > > second commit range, with unmatched commits being inserted just after > > all of their ancestors have been shown. > > > > +There are three ways to specify the commit ranges: > > + > > +- `<range1> <range2>`: Either commit range can be of the form > > + `<base>..<rev>`, `<rev>^!` or `<rev>^-<n>`. See `SPECIFYING RANGES` > > + in linkgit:gitrevisions[7] for more details. > > + > > +- `<rev1>...<rev2>`. This resembles the symmetric ranges mentioned in > > + the `SPECIFYING RANGES` section of linkgit:gitrevisions[7], and is > > + equivalent to `<base>..<rev1> <base>..<rev2>` where `<base>` is the > > + merge base as obtained via `git merge-base <rev1> <rev2>`. > > + > > +- `<base> <rev1> <rev2>`: This is equivalent to `<base>..<rev1> > > + <base>..<rev2>`. > > git-log takes a range, too. There you can specify a single rev (with the > semantic to list all commits from this rev up (or down?) to the root). > So <rev> means implicitly <rev>^∞..<rev> for git-log. > > Does it make sense to implement this here, too? Maybe this even allows > sharing some more code? I don't think that it makes sense to support open-ended ranges. `git range-diff` is expensive, its runtime is proportional to the number of patches in the first range times the number of patches in the second range. Allowing open-ended ranges will simply allow users to be stuck with a long runtime by mistake, and I do not see any valid use case in return for that risk. Ciao, Johannes
