list mirror (unofficial, one of many)
 help / color / Atom feed
From: Junio C Hamano <>
To: Denton Liu <>
Cc: Elijah Newren <>,
	Viresh Kumar <>,
	Git Mailing List <>,
Subject: Re: [Bug report] git diff stat shows unrelated diff
Date: Fri, 15 Feb 2019 11:28:51 -0800
Message-ID: <> (raw)
In-Reply-To: <20190215185202.GA28019@dev-l>

Denton Liu <> writes:

> On Thu, Feb 14, 2019 at 02:10:53PM -0800, Junio C Hamano wrote:
>> 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?

I doubt that such a change helps anybody more than it hurts.
Defining A..B to mean something totally different based on a hidden
config will hurt those who want to help others.  It would even hurt
those who are new to Git and blindly set such configuration because
their local guru tells them to and then goes on to read code
snippets and docs on the web outside our control that have been
written with the established meaning of what A..B and A...B mean to
"git diff".

There is nothing sensible in using dots, i.e. range notation,
between A and B _if_ you are trying to compare A and B, i.e. two
endpoints.  Just use "diff A B" and you are OK.

  parent reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-14  8:22 Viresh Kumar
2019-02-14 18:42 ` Johannes Sixt
2019-02-14 21:23 ` Elijah Newren
2019-02-14 22:10   ` Junio C Hamano
2019-02-15 18:52     ` Denton Liu
2019-02-15 19:25       ` Elijah Newren
2019-02-15 20:12         ` Junio C Hamano
2019-02-15 22:48           ` Philip Oakley
2019-02-15 23:32             ` Junio C Hamano
2019-02-16 12:47               ` Philip Oakley
2019-02-17  3:34                 ` Junio C Hamano
2019-02-17 23:34                   ` Philip Oakley
2019-02-18  0:21                     ` Junio C Hamano
2019-02-15 19:28       ` Junio C Hamano [this message]
2019-02-15  6:40   ` Viresh Kumar
2019-02-15 16:09     ` Elijah Newren
2019-02-18  4:34       ` Viresh Kumar

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:

AGPL code for this site: git clone public-inbox