Re: [PATCH 2/5] diff --quiet

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

That's not true. The --quiet option is not about comparing at the tree level vs looking inside the blobs. It helps to optimize the tree level comparison as well. The difference Linus was happy about comes from exactly the early exit from tree comparison.

The current --quiet will report if they are different at the tree level and does not take filtering done at the later phases into account at all, and that is a conscious design decision so that we can use it for optimizing try_to_simplify_commit(). So for example, if you have any change that a plain "git diff-*" says there are differences, the option reports there indeed are differences, like this:

	$ git reset --hard ;# start from the clean state
        $ touch Makefile
        $ git diff-files -p
        diff --git a/Makefile b/Makefile
        $ git diff-files --quiet; echo $?
	1

I didn't consider -w nor -b when I made the design decision that leads to the above behaviour, but I think the filtering done at the textual patch generation phase falls into the same category. If you do the following, the answer would be "they are different":

	$ sed -e 's/$/ /' <Makefile >Makefile+
        $ cat Makefile+ >Makefile
        $ rm Makefile+
        $ git update-index --refresh
        $ git diff-files -b -p
        diff --git a/Makefile b/Makefile
        index dc024d4..1c328be 100644
        $ git diff-files -b -p --quiet; echo $?
        1

Options like -w and -b are only about not showing the lines; you still get the diff header that reports they are different. So in that sense the output from the last command above is correct.

I am however wondering if we want to have (and if it would be worth the trouble to add) an option to have the command say if there will be textual difference output without producing it. I do not see much value in it right now, but it might turn out to be handy. I do suspect that would be a rather intrusive and error prone change, though.

A good news is that such an option needs to work at a different level than the existing --quiet, which works in diffcore_std(). The new option would probably need to work inside diff_flush() which is a later phase. So no matter how you screw up, it would hopefully not break revision traversal too much.

We might want to rename the existing one --quick and name that new option --quiet, though, if we go that route.