Re: [Bug report] git diff stat shows unrelated diff

>
> On Thu, Feb 14, 2019 at 02:10:53PM -0800, Junio C Hamano wrote:
> > Elijah Newren <newren@gmail.com> writes:
> >
> > > The only thing I seem to be able to retain is the following:  "git
> > > diff D..E is totally useless and should be an error because (1) it
> > > doesn't do what I expect and (2) for folks that want the behavior
> > > currently gotten with that syntax can instead just use a space instead
> > > of a double dot."
> >
> > That sums up pretty nicely.  diff is fundamentally an operation
> > between two endpoints, so the range notation a..b does not work
> > nicely with it at the conceptual level.
> >
> > When we realized that we can take advantage of the above fact, and
> > reuse a range notation to mean something that is generally useful in
> > the context of diff, such as 'one end of the comparison is the merge
> > base between a and b, and the other end is b', it was too late to
> > use "a..b", as an early adopters of Git was already used to the fact
> > that "a..b" happened to mean the same thing as "comparison of one
> > end is a, the other end is b", pretty much implemented without much
> > thought.
> >
> > It might be _possible_ to spend a year (i.e. 4 cycles) to start
> > warning when two-dot notation is used for "git diff" (only, not any
> > plumbing like "git diff-files") and tell the user to use the more
> > logical two-end notation "git diff A B" and then eventually error
> > out when two-dot notation is used, while retaining the three-dot
> > notation throughout and to the eternity.  I am not sure if it is
> > worth the deprecation cost, though.
> >
> Instead of outright deprecating it, would it make sense to include a
> configuration option, say "diff.sensibleDots", that would enable a user
> to set the dots to the other form if they desire?