In the following usecase git apply (git version 1.5.4.rc3.15.g785f9)=20
doesn't do what I expect it should do. I expect it to do the same as=20
patch does in the same situation.

To reproduce;
Create a file 'test' with a number on each line.  Numbers 1 though 10.
$ for i in 1 2 3 4 5 6 7 8 9 10; do echo $i >> test; done
$ git add test
$ git commit test

$ rm test
$ for i in 1 3 4 5 6 7 10; do echo $i >> test; done
$ git diff-index -p --unified=3D0 HEAD test | tee mypatch

Now use your editor to edit 'mypatch' and remove the first hunk; the end=20
result (after your editing) should be something like this;
$ cat mypatch
diff --git a/test b/test
index f00c965..319869c 100644
=2D-- a/test
+++ b/test
@@ -8,2 +6,0 @@
=2D8
=2D9

apply revert this patch;
$ git apply -R --unidiff-zero --apply mypatch
$ git diff

What I expect (and what I get if I replace git apply with a 'patch -R -p1=20
< mypatch') is that the diff shows line "2" is still missing.

What I get instead is that "2" is missing but also that "10" moved 2 lines=
=20
up.
I conclude that git somehow doesn't like the patch to be removed, while=20
patch(1) has no problem with that.

I hope you agree its a bug and fix it in an upcoming version, it would be=20
great if I can avoid using patch(1) or worse.
If you have any questions feel free to ask; but please cc me as I am not=20
subscribed.
=2D-=20
Thomas Zander