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: "Git Mailing List" <git@vger.kernel.org>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Andreas Schwab" <schwab@linux-m68k.org>,
	"Duy Nguyen" <pclouds@gmail.com>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Johannes Sixt" <j6t@kdbg.org>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Philip Oakley" <philipoakley@iee.org>,
	"Vincent Guittot" <vincent.guittot@linaro.org>,
	"Viresh Kumar" <viresh.kumar@linaro.org>
Subject: Re: [PATCH] git-diff.txt: prefer not using <commit>..<commit>
Date: Thu, 21 Mar 2019 06:58:31 -0700	[thread overview]
Message-ID: <CABPp-BGg_iSx3QMc-J4Fov97v9NnAtfxZGMrm3WfrGugOThjmA@mail.gmail.com> (raw)
In-Reply-To: <20190320172809.GA17593@dev-l>

Hi Denton,

On Wed, Mar 20, 2019 at 10:28 AM Denton Liu <liu.denton@gmail.com> wrote:
>
> Hi Elijah,
>
> Sorry for the late reply, I've been mulling over it for the past couple
> of days.

No worries; thanks for thinking about it.

> On Mon, Mar 18, 2019 at 10:59:56AM -0700, Elijah Newren wrote:
> > On Sun, Mar 17, 2019 at 4:09 AM Denton Liu <liu.denton@gmail.com> wrote:
> > >
> > > The documentation used to consider
> > >
> > >         git diff <commit> <commit>
> > >
> > > and
> > >
> > >         git diff <commit>..<commit>
> > >
> > > to be equal counterparts. However, rev-list-ish commands also use the
> > > <commit>..<commit> notation, but in a logically conflicting manner which
> > > was confusing for some users (including me!).
> > >
> > > Deprecating the notation entirely is not really an option because it
> > > would be an arduous process without much end-value. In addition, there
> > > are some valid use-cases that we don't want to break.
> >
> > Yes, there were multiple people who commented that they liked to
> > copy-paste the "A..B" output from fetch/pull in combination with diff
> > and log (even though one suggested that this gave the wrong output and
> > what they really wanted was "diff A...B").
> >
> > However, "removal of functionality" isn't the only form of
> > deprecation/warning.  Updating the manpage is another one which you
> > implemented, but I'd like to suggest yet another: Prefix the diff with
> > a warning message, e.g.
> >
> > "WARNING: You ran 'git diff A..B' (which means the same thing as 'git
> > diff A B').  Many users confuse 'git diff A..B' and 'git diff A...B'.
> > Please see 'git diff --help' for more details."
> >
> > Having extra text (e.g. commit message or warning) at the beginning of
> > the diff does not prevent tools like patch(1) or git-apply(1) from
> > successfully applying it, it still makes sense to humans (and who as
> > an added bonus happen to be really good at filtering out common
> > messages if they do encounter them more than a few times), and gives
> > us a chance in the future to figure out how to potentially extend the
> > message to make it a deprecation warning and/or provide details about
> > how to change the behavior of '..' to either be an error or behave
> > like triple dots or just not warn.
>
> I was originally planning on doing something like this (by warning to
> stderr, but your idea actually gets to the user ;) ). The only thing I'm
> worried about for a change like this is that it'll be very controversial
> since, as we could see anecdotally, a lot of people have trained
> themselves to use the .. form.
>
> In terms of backwards compatibility, I think that there's the
> possibility of breaking some scripts by doing this change but we could
> mitigate this by detecting if we're outputting to a terminal and only
> print the message in that case.

I don't see why anything would break if we just always showed the
warning.  git diff's purpose is to create a "patch", and as such can
be used by the patch(1) command.  We added additional headers in 'git
diff' relative to diff(1), but it's still understandable by patch.  We
also created git-apply because it could potentially make use of the
extra headers to do slightly smarter stuff than patch.  But both allow
arbitrary extra initial text as long as it doesn't have the relevant
start-of-next-diff-hunk characters.  Extra text at the beginning (an
explanation or a commit message or a warning or whatever) thus doesn't
change it from being a valid patch.

Human beings will see a little extra text by default, but they already
usually skip right over the diff headers when reading; this is
essentially just another diff header.  And we could provide them with
a config option to turn it off if they used it all the time and found
the two extra lines of text annoying.

Since both Ævar and I noted that even among people who use '..' lots
of them use it erroneously, it seems like a worthwhile warning to add,
to me at least.  That is, unless I've misunderstood my purpose of
'git-diff' as creating a patch or missed something else important.


Anyway, just my $0.02.  (And I'd be happy to take this on later if you
don't want to).
Elijah

      reply	other threads:[~2019-03-21 13:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-17 11:09 [PATCH] git-diff.txt: prefer not using <commit>..<commit> Denton Liu
2019-03-17 13:24 ` Duy Nguyen
2019-03-18  6:45   ` Junio C Hamano
2019-03-19  1:12     ` Denton Liu
2019-03-21 14:12     ` Johannes Schindelin
2019-03-17 13:40 ` Ævar Arnfjörð Bjarmason
2019-03-17 14:01   ` Duy Nguyen
2019-03-17 14:12     ` Ævar Arnfjörð Bjarmason
2019-03-18  6:47       ` Junio C Hamano
2019-03-18 17:46   ` Elijah Newren
2019-03-18 19:07     ` Ævar Arnfjörð Bjarmason
2019-03-19  0:56       ` Junio C Hamano
2019-03-20 14:21       ` Elijah Newren
2019-03-18 17:59 ` Elijah Newren
2019-03-20 17:28   ` Denton Liu
2019-03-21 13:58     ` Elijah Newren [this message]

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-BGg_iSx3QMc-J4Fov97v9NnAtfxZGMrm3WfrGugOThjmA@mail.gmail.com \
    --to=newren@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=liu.denton@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=philipoakley@iee.org \
    --cc=schwab@linux-m68k.org \
    --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).