public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed

From: Jim Meyering <jim@meyering•net>
To: Junio C Hamano <gitster@pobox•com>
Cc: git list <git@vger•kernel.org>
Subject: Re: git-diff: must --exit-code work with --ignore* options?
Date: Sun, 30 Aug 2009 18:25:44 +0200	[thread overview]
Message-ID: <87skf9uv3r.fsf@meyering.net> (raw)
In-Reply-To: <7v7i087twu.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Fri, 22 May 2009 13:40:49 -0700")

Junio C Hamano wrote:
> Jim Meyering <jim@meyering•net> writes:
>> Junio C Hamano wrote:
>>> Jim Meyering <jim@meyering•net> writes:
>>>>
>>>>     # do this in an empty directory
>>>>     $ git init -q; echo>k; git add .; git commit -q -m. .; echo \ >k
>>>>     $ git diff --ignore-space-at-eol --quiet || echo bad
>>>>     bad
>>>
>>> I am slightly torn about this, in that I can picture myself saying that
>>> this is unintuitive on some different days, but not today ;-)
>>
>> Thanks for the quick reply.  Here's why I noticed:
>> ...
>
> It seems that today is already "some different day" ;-) We could do
> something like this patch.
>
> While in the longer term I think it may make the world a better place by
> being more consistent with what users expect, I am not sure at what
> revision boundary we should introduce such a semantic change.
>
> We could always declare this a bug and apply the "fix" at any time.  It's
> all perception ;-).
>
> -- >8 --
> Subject: [PATCH] diff --quiet: special case "ignore whitespace" options
>
> The option "QUIET" primarily meant "find if we have _any_ difference as
> quick as possible and report", which means we often do not even have to
> look at blobs if we know the trees are different by looking at the higher
> level (e.g. "diff-tree A B").  As a side effect, because there is no point
> showing one change that we happened to have found first, it also enables
> NO_OUTPUT and EXIT_WITH_STATUS options, making the end result look quiet.
>
> Traditionally, the --ignore-whitespace* options have merely meant to tell
> the diff output routine that some class of differences are not worth
> showing in the textual diff output, so that the end user has easier time
> to review the remaining (presumably more meaningful) changes.  These
> options never affected the outcome of the command, given as the exit
> status when the --exit-code option was in effect (either directly or
> indirectly).
>
> These two classes of options are incompatible.  When you have only
> whitespace changes, you would expect:
>
> 	git diff -b --quiet
>
> to report that there is _no_ change.  This is unfortunately not the case,
> however, if there are differences to be reported if the command was run
> without --quiet; there _is_ a change, and the command still exits with
> non-zero status.
>
> And that is wrong.
>
> Change the semantics of --ignore-whitespace* options to mean more than
> "omit showing the difference in text".  When these options are used, the
> internal "quick" optimization is turned off, and the status reported with
> the --exit-code option will now match if any the textual diff output is
> actually produced.
>
> Also rename the internal option "QUIET" to "QUICK" to better reflect what
> its true purpose is.

Thanks again.
If there's anything I can to do help (add a test?), let me know.

next prev parent reply	other threads:[~2009-08-30 16:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-22 14:01 git-diff: must --exit-code work with --ignore* options? Jim Meyering
2009-05-22 16:14 ` Junio C Hamano
2009-05-22 17:54   ` Jim Meyering
2009-05-22 20:40     ` Junio C Hamano
2009-05-23  7:26       ` Jim Meyering
2009-08-30 16:25       ` Jim Meyering [this message]
2009-08-30 20:11         ` Junio C Hamano
2009-08-30 20:27           ` Jim Meyering
2009-09-08 20:58           ` Thell Fowler

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=87skf9uv3r.fsf@meyering.net \
    --to=jim@meyering$(echo .)net \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    /path/to/YOUR_REPLY

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox