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.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.