Re: [PATCH] git diff -D: omit the preimage of deletes

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

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> I would have expected that the patch relative to jc/diff-irreversible-delete
>> topic would consist only of changes to diff.c:emit_rewrite_diff(), docs
>> and tests.
>
> Here is an "in other words" follow-up.  Your tests looked reasonable (and
> pass with this patch on top of what has been queued in 'pu').

And this is the documentation part, based on your version but somewhat
rewritten.  Your version said "cannot be applied with -R", but at the
mechanical application level, the format is deliberately designed to make
`patch` and `git apply` to fail, and I think that should be mentioned
together with the reason why such an option exists (i.e. for human eyeball
consumption).

I'll squash these two to what is queued in 'pu'.  We may want to polish it
again after 1.7.5 but I think it is in much better shape now.

Thanks.

 Documentation/diff-options.txt |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index c93124b..30a00d3 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -259,6 +259,19 @@ endif::git-log[]
 	projects, so use it with caution.  Giving more than one
 	`-C` option has the same effect.
 
+-D::
+--irreversible-delete::
+	Omit the preimage for deletes, i.e. print only the header but not
+	the diff between the preimage and `/dev/null`. The resulting patch
+	is not meant to be applied with `patch` nor `git apply`; this is
+	solely for people who want to just concentrate on reviewing the
+	text after the change. In addition, the output obviously lack
+	enough information to apply such a patch in reverse, even manually,
+	hence the name of the option.
++
+When used together with `-B`, omit also the preimage in the deletion part
+of a delete/create pair.
+
 -l<num>::
 	The `-M` and `-C` options require O(n^2) processing time where n
 	is the number of potential rename/copy targets.  This