$ mkdir test_repo $ cd test_repo/ $ git init Initialized empty Git repository in /home/labbott/test_repo/.git/ $ touch foo $ git add foo $ git commit -m "this file" [ master (root-commit) c51ba67] this file 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 foo $ cp ~/a.out . $ file a.out a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=96d6131eb203b850d42b53a7f5ebc512056ec739, not stripped $ git add a.out $ git commit -m "A binary file" [master d5bdd17] A binary file 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100755 a.out $ git rm a.out rm 'a.out' $ git commit -m "no binary" [master 9dd9f2b] no binary 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100755 a.out $ git format-patch -1 --no-binary HEAD 0001-no-binary.patch $ git reset --hard HEAD^ HEAD is now at d5bdd17 A binary file $ patch -p1 < 0001-no-binary.patch patching file a.out Not deleting file a.out as content differs from patch $ echo $? 1 $ cat 0001-no-binary.patch From 9dd9f2b6c717d4125d790610941f258bdb573ee4 Mon Sep 17 00:00:00 2001 From: Laura Abbott <firstname.lastname@example.org> Date: Wed, 2 Dec 2015 10:45:33 -0800 Subject: [PATCH] no binary --- a.out | Bin 8784 -> 0 bytes 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100755 a.out diff --git a/a.out b/a.out deleted file mode 100755 index 3772793..0000000 Binary files a/a.out and /dev/null differ -- 2.5.0 $
This is the story behind a recent bugzilla. The patches generated on kernel.org only say that the binary files changed so they can't actually be applied as diffs. Git deals with binary files just fine though so it's possible to sneak some in and end up with a tree that can't be easily expressed in patches. Binary files usually don't have a place in the kernel, but some did come in with a staging driver. The staging driver was deleted this merge window. Everything that isn't an official x.y kernel release (e.g. 4.3-rc4, 4.2.3) comes in as a patch file so all patches are going to be unappliable until that commit makes it into an official release. The workaround right now is to modify the patch to get rid of the binary file deletion. This does mean the checksums aren't going to match against kernel.org but this is only going to be the case until the next official release in rawhide which should be sometime at the beginning of January. You'll just have to trust the Fedora kernel team in the mean time.