list mirror (unofficial, one of many)
 help / color / mirror / 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's message of "Fri, 15 Feb 2019 10:52:02 -0800")

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	other threads:[~2019-02-15 19:28 UTC|newest]

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 publicly 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)

This inbox may be cloned and mirrored by anyone:

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

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ \
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
 note: .onion URLs require Tor:

code repositories for the project(s) associated with this inbox:

AGPL code for this site: git clone