Hi,

On Friday 03 September 2010 20:43:51 Jonathan Nieder wrote:

Uwe Kleine-K?nig wrote:

quoted

On Fri, Sep 03, 2010 at 07:18:43PM +0900, Magnus Damm wrote:

quoted

quoted

Using --dry-run is fine, but omitting dry-run gives me:

...
patching file arch/arm/common/clkdev.c
patching file arch/sh/include/asm/clkdev.h
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 11.
2 out of 2 hunks FAILED -- saving rejects to file
arch/sh/include/asm/clkdev.h.rej

I guess this is caused by the last "renaming" hunk, see below.

Yep, I can reproduce this.  Patch applies with "git apply",
"patch --dry-run -p1" accepts it, "patch -p1" fails.

 $ patch --version | head -1
 GNU patch 2.6.1.85-423d
 $ cd ~/src/linux-2.6
 $ git checkout 2bfc96a12
 $ git clean -fd
 $ wget http://download.gmane.org/gmane.linux.ports.sh.devel/8747/8748
[...]

something pretty bizarre is going on here.  The wget output modifies the same 
file twice, but both patches to this file have the same source sha1 (5645f35):

So "git apply" and "patch --dry-run" seem to work only by accident.

How was this patch generated: with git itself?

The fact that "patch --dry-run" may not work for patches that modify the same 
file twice is a known defect.  I don't know how to solve this in a reasonably 
elegant way.  Luckily the problem only triggers when people are doing 
something "strange" such as concatenating patches.

Andreas