Re: git-diff: must --exit-code work with --ignore* options?
- From
Jim Meyering <jim@meyering.net>
- Date
- May 22, 2009, 17:54 UTC
- Message-ID
- <87eiuhdnw9.fsf@meyering.net>
- In-Reply-To
- <7vvdnt869j.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
Show 19 quoted lines
> 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 $?
0Show 9 quoted lines
> 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.
Show 6 quoted lines
> 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.