Subject: Re: [PATCH v6 17/21] range-diff: populate the man page

From: Junio C Hamano <[email-masked]>
Date: Mon, 10 Sep 2018 10:17:17 -0700

Ævar Arnfjörð Bjarmason <[email-masked]> writes:

> Looking at the git-range-diff manpage though it recommends <base> <rev1>
> <rev2> over <rev1>...<rev2> when the topic has been rebased, which is
> usually the case for e.g. a topic that's submitted to git.git (usually
> be the time feedback has been gathered & a re-submission has been made
> Junio has pushed another "master").
>
> So isn't "<base> <rev1> <rev2>" the right thing to use over
> "<rev1>...<rev2>" for git.git use? I think so, but I'm not sure.

If <rev2> is forked from different base than where <rev1> was
forked, then <base> <rev1> <rev2> would give you more sensible
range.  And such an update is inevitable when <rev2> must rely on
new things that recently appeared on <base> since <rev1> forked from
the mainline.  But otherwise <rev1>...<rev2> should work just fine.

> In any case, there are going to be those use-case where you should be
> using "<base> <rev1> <rev2>", and a rebase will be propagated by a
> force-push, so I thought it made sense that range-diff could directly
> consume the output of "fetch" in that case...

I am not absolutely sure if there is *more* useful interpretation
that "<base> <rev1>...<rev2>" may want to mean than to serve as a
synonym for "<base> <rev1> <rev2>" for those who are too lazy to
type.  But if there isn't, I'd say it is a reasonable synonym to
want.