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: Fri, 22 May 2009 19:54:14 +0200	[thread overview]
Message-ID: <87eiuhdnw9.fsf@meyering.net> (raw)
In-Reply-To: <7vvdnt869j.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Fri, 22 May 2009 09:14:00 -0700")

Junio C Hamano wrote:
> Jim Meyering <jim@meyering•net> writes:
>> git-diff's --quiet option works how I'd expect with --ignore-space-at-eol
>> as long as I'm also using --no-index:
>>
>>     $ echo>b; echo \ >c; git diff --no-index --quiet --ignore-space-at-eol b c \
>>       && echo good
>>     good
>>
>> But in what I think of as normal operation (i.e., without --no-index),
>> --exit-code (or --quiet) makes git-diff say there were differences,
>> even when they have been ignored:
>>
>>     # 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:

I wanted to ensure that the only changes induced by commit C were
to trailing blanks.  I wrote something like this, expecting to be able
to deal with the exception:

    git --quiet --ignore-space-at-eol --quiet C^..C || handle_unexpected

But handle_unexpected was always being invoked.
I was surprised because GNU diff's --ignore-all-space (-w) option does
work the way I expected:

    $ echo>b; echo \ >c; diff -w b c && echo $?
    0

> If you look at the output (i.e. no --quiet), you would see that the blob
> changes are still reported for the path.  E.g.  you would see something
> like...
>
> 	$ git diff --ignore-space-at-eol
>         diff --git a/k b/k
>         index 8b13789..8d1c8b6 100644
>
> The "index" line is still showing that there _is_ a difference.

I did see that, to my chagrin:
if using a --ignore-... option had also suppressed those, I could
have tested for empty output instead of exit status.

> The --ignore-* options are there merely to tell git what changes are not
> worth _showing_ in the textual part of the patch, in order to cut down the
> amount of the output.  It never affects the outcome.
>
> So if anything, I think --no-index codepath is what's buggy; if it does
> not report the blob difference that is a different matter, though.

If need be, I can work around it.

next prev parent reply	other threads:[~2009-05-22 17:54 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 [this message]
2009-05-22 20:40     ` Junio C Hamano
2009-05-23  7:26       ` Jim Meyering
2009-08-30 16:25       ` Jim Meyering
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=87eiuhdnw9.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