Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> The point I tried to make: without "-w" or "-b", you can compare at the
> tree level. No need for a --quiet option.
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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html