that does not have anything between "deleted file..." and the next diff about libata-core.c.
In short, this is not really a "bug", but I am open to suggestions for improvements (but you need to talk Linus into accepting the changes, because changing this would also affect his "git-apply" program as well).
The current "diff-patch" format is generated this way:
(0) if a modification is between different kind of objects
(e.g. a regular file changed to a symlink), then the
following steps are done twice; one "deletion" of the
original, and another "creation" of the result. (1) "diff --git a/oldname b/newname" line is shown first and it
is always shown. Unless it is a rename/copy diff, oldname
and newname always match. We never say /dev/null on this
line to represent creation/deletion. (2) Next, optional "diff --git extended headers" appear. See
apply.c for the list of things to expect. (3) Next, the output from "diff -u -L<oldname> -L<newname>"
between the two file contents follows. Here, oldname and
newname are usually of the form "a/oldname" and
"b/oldname", but we _do_ follow /dev/null convention for
file creation and deletion here. That is, you would see --- /dev/null
+++ frotz.c
@@ ... for a file creation, and the opposite for a file deletion.
Unfortunately, if "diff" finds nothing to report, you would
not even see these ---/+++ lines. I think that is what
puzzled you.By the way, this is all documented (?) behaviour, reported first by Linus in this message.
Message-ID: <Pine.LNX.4.58.0505261214140.2307@ppc970.osdl.org>
From: Linus Torvalds <torvalds@osdl.org>
Subject: git full diff output issues..
Date: Thu, 26 May 2005 12:19:21 -0700 (PDT)
Cc: Git Mailing List <git@vger.kernel.org>
While testing my "git-apply" thing (coming along quite nicely, thanks for
asking), I've hit a case that is nasty to parse.
This is from the 2.6.12-rc4 -> 2.6.12-rc5 patch:
diff --git a/arch/um/kernel/checksum.c b/arch/um/kernel/checksum.c
deleted file mode 100644
diff --git a/arch/um/kernel/initrd.c b/arch/um/kernel/initrd.c
new file mode 100644
--- /dev/null
+++ b/arch/um/kernel/initrd.c
@@ -0,0 +1,78 @@ and the magic here is that deleted file that was empty to begin with, so
it didn't have a patch, just a note on deletion.
Why is that nasty? Because we don't have the file _name_ in any good
format. The filename only exists int he "diff --git" header, and that one
has the space-parsing issue, which makes it less than optimal.
(the rest omitted)
We had a handful of back-and-forth back then and the resolution was this:
Message-ID: <Pine.LNX.4.58.0505261316250.2307@ppc970.osdl.org>
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: git full diff output issues..
Date: Thu, 26 May 2005 13:33:26 -0700 (PDT)
Cc: Junio C Hamano <junkio@cox.net>, Git Mailing List <git@vger.kernel.org>
(some omitted)
However, I ended up just validating the name parsing by making sure that
when I parse the "git --diff" line, I only take the name if I can see it
being the same for both the old and the new. ...
(the rest omitted)
By the way, this is not just "deleting empty files". Any change that does not involve content changes you would see something similar to what you found.
Message-ID: <Pine.LNX.4.58.0506050806400.1876@ppc970.osdl.org>
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: git full diff output issues..
Date: Sun, 5 Jun 2005 08:11:02 -0700 (PDT)
Cc: git@vger.kernel.org
(some omitted)
The only case that was special was literally the "same name, no content
changes, new mode" case, which looked like
diff --git a/oldname.c b/oldname.c
new mode 100755
old mode 100644 and thus _only_ had the name in the (normally ambiguous wrt whitepsace)
header line.
