Ralf Baechle <ralf@xxxxxxxxxxxxxx> writes:
> 27fdd325dace4a1ebfa10e93ba6f3d25f25df674^ and apply Yoichi's patch using
> git am or git apply this will leave a zero byte drivers/char/vr41xx_giu.c.
> Patch(1) otoh will remove that file as expected. The patch file Yoichi
> sent looks perfectly ok; here the headers of the vr41xx_giu.c bit:
>
> [...]
> diff -pruN -X /home/yuasa/Memo/dontdiff linux-orig/drivers/char/vr41xx_giu.c linux/drivers/char/vr41xx_giu.c
> --- linux-orig/drivers/char/vr41xx_giu.c 2009-06-29 10:06:58.329177629 +0900
> +++ linux/drivers/char/vr41xx_giu.c 1970-01-01 09:00:00.000000000 +0900
> @@ -1,680 +0,0 @@
> -/*
If you look for -E option in "man patch" and find that it says "causes
patch to remove output files that are empty after the patches have been
applied.", you will realize that your claim that "patch(1) otoh ... as
expected" does not match the reality for everybody. It is true only if
you _are_ explicitly asking to remove such an empty file.
The recent diff specification (at least the one in POSIX.1) says that file
removal is marked by the UNIX epoch timestamp you see there, instead of a
more recent timestamp. IOW, you should _in theory_ be able to tell by
looking at the 1970-01-01 timestamp that the intention of this patch is
not to make the file empty, but is to remove.
But in practice, because traditionally GNU diff and other people's diff
placed pretty arbitrary garbage after the TAB that follows the filename,
patch does not rely on that convention to detect a removal patch. Notice
that even -E option does not pay attention to that timestamp line, but
removes files that become _empty_.
Neither do we. The patch application toolchain in "git" does not have -E
option and the above patch is interpreted just like traditional patch does
by default: the file goes empty.
The output from "git diff" is designed so that (1) it can distinguish the
removal case and the goes-empty case more clearly, and also that (2) it
can be safely used by patch(1). A removal patch from git looks like:
diff --git a/file b/file
deleted file mode 100644
index 363ef61..0000000
--- a/file
+++ /dev/null
@@ -1 +0,0 @@
-original contents
while "goes empty" patch looks like:
diff --git a/file b/file
index 363ef61..e69de29 100644
--- a/file
+++ b/file
@@ -1 +0,0 @@
-original contents
and when applied with git, they both produce "expected" results.
We _could_ add -E option to "git apply" and pass that through "git am" to
support projects like the kernel where 0-byte files are forbidden. A
patch to do that shouldn't be too involved.
