All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gummerer <t.gummerer@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Denton Liu <liu.denton@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>,
	Joel Teichroeb <joel@teichroeb.net>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Junio C Hamano <gitster@pobox.com>,
	Matthew Kraai <mkraai@its.jnj.com>
Subject: Re: [REGRESSION ps/stash-in-c] git stash show -v
Date: Wed, 20 Mar 2019 21:59:16 +0000	[thread overview]
Message-ID: <20190320215916.GD32487@hank.intra.tgummerer.com> (raw)
In-Reply-To: <20190320050449.GA6401@sigill.intra.peff.net>

On 03/20, Jeff King wrote:
> On Tue, Mar 19, 2019 at 11:18:26PM +0000, Thomas Gummerer wrote:
> 
> > From a quick search I couldn't find where 'git diff' actually parses
> > the '-v' argument, but I wonder if we should actually disallow it, in
> > case we want to use it for something else in the future?  It's not
> > documented anywhere in the docs either.
> 
> It's a bit interesting, actually. git-diff uses setup_revisions() to
> parse its arguments, which picks up any diff options, as well as parsing
> the revs and pathspecs.
> 
> But it also means we accept any random revision options. So nonsense
> like:
> 
>   git diff --ancestry-path HEAD^ HEAD
> 
> is accepted, even though nobody ever looks at the flags set by parsing
> that option.
> 
> And "-v" is mostly in the same boat. It works more or less like --pretty
> (try rev-list with and without it), and does nothing for an endpoint
> diff. What's a little interesting, though, is that it was originally
> added as a diff-tree option in the very early days, via cee99d2257
> (diff-tree: add "verbose header" mode, 2005-05-06). And the reason there
> is that "diff-tree --stdin" filled a "log"-like role; it didn't traverse
> the commits itself, but it was responsible for showing them.

Thanks for the explanation!

> Most of that is historical curiosity, but I think the takeaways are:
> 
>   - we probably should use a less bizarre option to demonstrate this bug
>     (Junio suggested --patience, which makes perfect sense to me)

Yep, that should make the test a bit easier to understand.  Will do
that in v2.

>   - we may want to teach the "diff" porcelain not to accept useless
>     revision options. I suspect it may be a bit tricky, just because of
>     the way the code takes advantage of setup_revisions.  It would also
>     be nice if "diff-tree" in non-stdin mode could do the same, but I
>     suspect that is even trickier (we do not even know whether we are in
>     --stdin mode or not until we've fed the options to setup_revisions).
>     So I'd guess this is not really worth the effort it would take.
> 
>   - "-v" is a real thing; we should consider either documenting it or
>     deprecating it.

Makes sense, I don't have a strong opinion on which way we should go
here, but I'll leave that separately from the bug fix either way.

  parent reply	other threads:[~2019-03-20 21:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-19 19:05 [REGRESSION ps/stash-in-c] git stash show -v Denton Liu
2019-03-19 23:18 ` Thomas Gummerer
2019-03-20  1:00   ` Junio C Hamano
2019-03-20 21:45     ` Thomas Gummerer
2019-03-20  1:04   ` Junio C Hamano
2019-03-20  5:04   ` Jeff King
2019-03-20  9:30     ` Duy Nguyen
2019-03-20 21:59     ` Thomas Gummerer [this message]
2019-03-20 22:49   ` [PATCH v2] stash: setup default diff output format if necessary Thomas Gummerer
2019-03-20 23:04     ` Denton Liu
2019-03-20 23:09     ` Denton Liu
2019-03-28 20:45       ` Thomas Gummerer
2019-03-21  9:51     ` Jeff King
2019-03-22  3:25       ` Junio C Hamano
2019-03-22  3:48         ` Jeff King

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

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

  git send-email \
    --in-reply-to=20190320215916.GD32487@hank.intra.tgummerer.com \
    --to=t.gummerer@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=joel@teichroeb.net \
    --cc=liu.denton@gmail.com \
    --cc=mkraai@its.jnj.com \
    --cc=peff@peff.net \
    --cc=ungureanupaulsebastian@gmail.com \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.