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


> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to