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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 10, 2018, 17:17 UTC
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:

Show 8 quoted lines

> 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.