git apply behaves differently from patch(1)

From: Thomas Zander <zander@kde.org>
Date: Jan 16, 2008, 22:58 UTC
Message-ID: <200801162358.48723.zander@kde.org>

In the following usecase git apply (git version 1.5.4.rc3.15.g785f9) doesn't do what I expect it should do. I expect it to do the same as 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=0 HEAD test | tee mypatch

Now use your editor to edit 'mypatch' and remove the first hunk; the end result (after your editing) should be something like this; $ cat mypatch

diff --git a/test b/test
index f00c965..319869c 100644
--- a/test
+++ b/test
@@ -8,2 +6,0 @@
-8
-9

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 
< 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 
up.
I conclude that git somehow doesn't like the patch to be removed, while 
patch(1) has no problem with that.

I hope you agree its a bug and fix it in an upcoming version, it would be 
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 
subscribed.

-- 
Thomas Zander