Re: [PATCH] git-diff.txt: prefer not using <commit>..<commit>

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> Some of this thread's confusing, and on re-reading I see my reply hasn't
> helped much.
>
> To clarify. There's at least these things to consider:
>
> 1. What should the semantics of .. or ... be?
> 2. What semantics (regardless of syntax) should we recommend for common cases?
> 3. Depending on #1 and #2, can we make our docs less confusing?

Nice way to summarise.

> My opinion:
>
> 1. I'd ideally like to switch the semantics of ".." and "...". I don't
>    think anyone argues that it would be a bad thing in theory if we'd
>    started out that way, Whether it's worth switching now is another
>    matter.
>
>    Junio chimed in in <xmqqmum0h88n.fsf@gitster-ct.c.googlers.com>
>    saying he's not for it, so I'm assuming it's out for now.

I do agree with the "in the ideal world, where we didn't have any
existing users and had perfect foresight back when invention of
three-dot form for 'log' was even a few months away down the road,
we would have used diff A...B for the two-endpoints", and I also
agree with "that is 10 years or more too late now---don't waste time
even pondering about it".
>
> 2. I agree that we should generally recommend what's now "..." instead
>    of "..", whatever the syntax is to invoke that.

I do not agree with this at all.  When I want to compare what is in
devel and what is in master, I may be interested in two completely
different things depending on why I am doing the comparison.

 - I may want to know "what is in the development track that is yet
   to be merged to 'master'".

 - Or I may be looking for "what is the difference between the master
   branch and the development branch."

The latter should match the former if 'devel' and 'master' means
what we generally think they are, and by looking at the latter, I
can find what would be missed if I wholesale replace 'master' with
'devel' before merging 'master' backwards into 'devel' to make the
latter catch up.  So even in that context, I would prefer to see the
latter (needless to say, the start-up cost is far less for the
latter than for the former).

When we discuss a more generic "two endpoints comparison" whose
relationship between the two endpoints is not as well-defined as
'devel' and 'master' (i.e. what does it mean to compare v1.2.1 and
v1.3.4?), I can phrase in human-understandable terms what ".." does,
but not what "..." does.  I have no idea how you or anybody can say
that "we should generally recommend" that the former is the norm and
two-endpoint comparison is an exception.