Jeff King <peff@xxxxxxxx> 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.
--
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