git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <newren@gmail.com>
To: Denton Liu <liu.denton@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Git Mailing List <git@vger.kernel.org>,
	vincent.guittot@linaro.org
Subject: Re: [Bug report] git diff stat shows unrelated diff
Date: Fri, 15 Feb 2019 11:25:43 -0800	[thread overview]
Message-ID: <CABPp-BEmPQb4Q_38S2A_68m+Cu75VDDD2UV0qWBDjL1OUAug9Q@mail.gmail.com> (raw)
In-Reply-To: <20190215185202.GA28019@dev-l>

On Fri, Feb 15, 2019 at 10:52 AM Denton Liu <liu.denton@gmail.com> wrote:
>
> 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?

I think Junio's suggested steps would still have to come first, and
there may also need to be a time period after two-dot notation is an
error before we were to try to repurpose it for something else (e.g.
to make it behave the same as triple-dot).  Adding a config to change
things now without both a deprecation and error period would invite
horrible surprises and bug reports; people need time and warning to
change workflows and fix existing scripts that might be out there.

> This has bugged me for long enough that if there's a desire for this
> from others, I'm willing take on the effort of making this change.

I was going to put the deprecation and erroring steps on my (always
growing) TODO list to eventually get to it, but if you're motivated,
go for it; I wouldn't get to it soon anyway.

  reply	other threads:[~2019-02-15 19:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-14  8:22 [Bug report] git diff stat shows unrelated diff 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 [this message]
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
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=CABPp-BEmPQb4Q_38S2A_68m+Cu75VDDD2UV0qWBDjL1OUAug9Q@mail.gmail.com \
    --to=newren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=liu.denton@gmail.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).