In some cases "patch" cannot apply diff's generated using git-diff, I've had a "git diff" output look like this when an empty file was removed as the only change: diff --git a/source3/include/dcerpc.h b/source3/include/dcerpc.h deleted file mode 100644 index e69de29..0000000 which patch rejected, saying: patch: **** Only garbage was found in the patch input. There is a ghastly diff notation recognized by patch, using the magic date 1970-01-01 01:00:00.000000000 to signify deletion which git-diff properly uses for non-empty files. Empty files are a different matter because there is no unified diff that can represent deletion of an empty file because patch doesn't like unified diff's with no context. However this equivalent pair works by making the file non-empty and then deleting it. diff -Nru 1/here 2/here --- 1/here 2008-11-05 09:43:55.000000000 +0000 +++ 2/here 2008-11-05 09:43:58.000000000 +0000 @@ -0,0 +1 @@ + diff -Nru 1/here 2/here --- 1/here 2008-11-05 09:37:23.000000000 +0000 +++ 2/here 1970-01-01 01:00:00.000000000 +0100 @@ -1 +0,0 @@ - In considering this filthy hack we should recognize that currently : * patch will choke on certain "git diff" output. If patch's exit code is checked as part of a loop of patches, then the patch procedure will fail. This happened to me * if delete-empty-file is one action in a larger patch file it will do nothing - which can be worse if the "existence" of a file affects the build system. This filthy hack fixes both problems. Sam -- 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