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

[Paul Gortmaker <paul.gortmaker@windriver.com>]

On 13-08-20 01:57 PM, Junio C Hamano wrote:
> 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.

OK, so given your feedback, how do you feel about a patch to the
documentation that indicates to use "-v" in combination with the
"--check" to get equivalent "patch --dry-run" behaviour?   If that
had existed, I'd have not gone rummaging around in the source, so
that should be good enough to help others avoid the same...

P.
--

> 
> 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".
>