From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 10 Sep 2018 17:17:17 GMT
Subject: Re: [PATCH v6 17/21] range-diff: populate the man page
Message-ID: <xmqqmusptgpu.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <87k1nu7fm0.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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.