Re: Should "git apply --check" imply verbose?

[Junio C Hamano <gitster@pobox.com>]

Paul Gortmaker <paul.gortmaker@windriver.com> writes:

> TL;DR -- "git apply --reject" implies verbose, but the similar
> "git apply --check" does not, which seems inconsistent.

Hmmm, I am of two minds.  From purely idealistic point of view, I
can see why defaulting both to non-verbose may look a more
attractive way to go, but I have my reservations that is more than
the usual change-aversion.

Historically, "check" was primarily meant to see if the patch is
applicable cleanly in scripts, and we never thought it would make
any sense to make it verbose by default.  

On the other hand, the operation of "reject", which was a much later
invention, was primarily meant to be observed by humans to see how
the patch failed to cleanly apply and where, to help them decide
where to look in the target to wiggle the rejected hunk into (even
when it is driven from a script).  It did not make much sense to
squelch its output.

In addition, because "check" is an idempotent operation that does
not touch anything in the index or the working tree, running with
"check" and then "check verbose" is possible if somebody runs it
without verbose and then decides later that s/he wants to see the
details.  But "reject" does touch the working tree files with
applicable hunks, so after a quiet "reject", there is no way to see
the verbose output like you can with "check".