On Fri, Nov 07, 2008 at 12:19:14PM -0800, Junio C Hamano wrote: > I am afraid that this is totally unacceptable, as you yourself mentioned, > the end result is unapplicable with any existing tool and would confuse > viewers like gitk and gitweb. Well, other tools will still have to be taught about a new syntax, if they're going to use the new flag - just like it was for --rename. That makes me think that it could be interesting to have a header telling which diff extensions it is using. It could even be interesting to come with a cross-vc convention, which would ease the interchange of modern patch files (I suppose some other tools already have their own extensions for file renames). What about some hint like the following ? |extended diff features: git:rename git:binary git:filetypes |extended diff features: git:unixperms git:dir-rename Maybe we could leave "filetype" and "unixperms" out, since these do not replace an information that would otherwise be present in a standard diff anyway, and would just be ignored by a tool not supporting them. > I think it would be a much better approach to emit a hint that talks about > directory rename in a format that does not fool usual "patch" application > tools. E.g. > > |directory moved with similarity index 82% > |rename from ppc > |rename from foo > |diff --git a/ppc/sha1.h b/foo/sha1.h > |similarity index 85% > |rename from ppc/sha1.h > |rename to foo/sha1.h > |index 9b34f76..8fce4b7 100644 > |--- ppc/sha1.h > |+++ foo/sha1.h > |@@ ... So you're favoring the "patch is not textually splittable approach". Don't you think it would be good to add some sort of hint about this as a patch header ? > IOW, do not add anything that begins with "diff --git" if it is not a > patch. OK. -- 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
