git apply behaves differently from patch(1)

git apply behaves differently from patch(1)

[Thomas Zander]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: git apply behaves differently from patch(1)

[Johannes Sixt]

Thomas Zander schrieb:
> 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;

[... hand-edit a patch without context ...]

> 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.

It's not exactly a bug. The behavior of zero-context patches is simply not
well-defined. You have just been lucky that patch worked in the way that
you expected. Don't use zero-context patches.

That said git-apply can certainly be modified to behave like patch in this
case. I tried, but gave up - it's too much code that is new to me. :(

-- Hannes

Re: git apply behaves differently from patch(1)

[Linus Torvalds]

On Wed, 16 Jan 2008, Thomas Zander wrote:
>
> 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.

There's actually a lot of cases where git-apply doesn't really do what 
patch does.

There's one really obvious difference, in that git-apply only does unified 
diffs and doesn't support any of the traditional ones: that may be seen as 
a downside, but I was never interested in them, so it's a "limitation" 
only in the sense that git-apply just doesn't do the ass-backwards old 
formats.

But this definitely means that "git-apply" doesn't really _replace_ patch 
per se.

There's also the very explicit differences, ie git-apply has all the 
extensions for renaming etc.

But in addition to those limitations and extensions there are the much 
subtler ones, which tend to come down to different interpretations of what 
is "safe".

What you hit is one such difference. There are others. They all boil down 
to "I'm not sure enough I can apply this correctly, so I won't":

 - (the one you hit): zero context at the end means "end-of-file"

   There's no other valid reason to have zero context in git-apply's 
   opinion, because without the context, there's no way to verify that 
   we're applying things in the right place.

 - git doesn't guess how deep the path is by default.

 - git does not accept any fuzz by default

In other words, git-apply simply doesn't want to apply unsafe patches. 
Yes, they often (probably 99% of the time) would apply in the right place, 
but partly *because* they often work, people are so used to doing them 
that then the few cases where they silently apply incorrectly are even 
more painful and often aren't noticed.

So no, git-apply really isn't a straight replacement for GNU patch. 

You can't really get exactly the same behaviour with any flags (there is 
no "guess filename path depth" mode at all, for example), but you can get 
fairly close with

	git-apply -C1 --unidiff-zero

where that -C1 matches GNU patches (INSANE!) default fuzz of 2, and the 
--unidiff-zero thing disables the stricter git-apply rules for no context.

I would actually suggest you go the other way: rather than try to make 
git-apply mimic the unsafe defaults of GNU patch, try to teach yourself to 
use the stricter rules. It's not always practical, but generally, the 
things git-apply refuses to do by default really *are* rather likely to 
mis-apply a patch occasionally.

(Even with git-apply's strict defaults, there is obviously no *guarantee* 
that a patch will always apply correctly, but at least git-apply will 
strictly check as much of the information that is available in the patch)

			Linus