Re: git diff: add option for omitting the contents of deletes

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 28, 2011, 18:11 UTC
Message-ID: <7vy650hvwa.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110228122335.GB5197@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> Actually, thinking on this a bit more, I guess "-M" and "-C" are usable
> without the sha1. In fact, we don't even provide it for a strict 100%
> rename, and for a rename-with-patch, you can apply the patch, assuming
> you have the original file in any form.

Yes, you got it correctly. A patch is about giving you an ability to propagate a change to a similar tree, that does not have to be identical to yours (otherwise you can just send tarball of the whole thing ;-)).

And a patch is not purely technical; it has human component in that the recipient needs to know enough about the context of the patch to be able to judge if the change is applicable to his tree. By seeing some context lines in -M/-C (many of them are not pure renames), the recipient can be sure that the patch is being applied to his tree that is "similar enough" to what the patch was originally produced against. It would certainly help to have git-apply that understands the rename patches to apply such a patch mechanically, but that is not a strict requirement; the recipient can move or copy the original file to manually create the target and apply the patch by hand to produce the desired result, so "do you have git?" is mostly irrelevant.

The proposed -D would apply to any tree that happens to have the path being mentioned in the patch regardless of how similar the target tree is to the original. Pure renaming -M/-C patch shares the same risk, but unlike these modes, -D goes one step too far by making it impossible to recover from lossage without having a backup.

But all of the above is only about principles. As I said, I am not strongly opposed to have an output mode that is primarily for reviewing, just like we have --color-words, that are not suitable for patch application, as long as users understand the implications.

It may make sense to show such a patch still with a bit of context, perhaps like this:

     README |   54 ------------------------------------------------------
     1 files changed, 0 insertions(+), 54 deletions(-)

    diff --git -D a/README b/README
    deleted file mode 100644
    index 67cfeb2..0000000
    --- a/README
    +++ /dev/null
    @@ -1,54 +0,0 @@
    -////////////////////////////////////////////////////////////////
    -
    -	GIT - the stupid content tracker
    -...
    -the discussion following them on the mailing list give a good
    -reference for project status, development direction and
    -remaining tasks.

so that the reader can have some warm and fuzzy feeling that the correct file is being deleted, though.