Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx> 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". -- 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