Re: diff-apply-hunk documentation doesn't match implementation

[Stefan Monnier]

>>>>> This is just one part of the implementation.  The behavior is actually
>>>>> pretty subtle (too subtle, admittedly).  So I can't judge without knowing
>>>>> which end-user-level behavior you're referring to.
>>>>> I look at a hunk, it says "Hunk not yet applied", I want to apply it, it
>>>>> applies it to the original instead of the file I look at.
>>>> Details please?
>>> What do you need?
>> Everything starting from "emacs -Q", including the patch file.

> $ wget ftp://lwfinger.dynalias.org/patches/combined_2.6.20.2.patch
> $ wget 
> ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.21-rc3.tar.bz2
> $ tar -xf linux-2.6.21-rc3.tar.bz2
> $ cp -a linux-2.6.21-rc3 linux-2.6.21-rc3.orig
> $ emacs combined_2.6.20.2.patch
> C-c C-f
> M-n M-4 M-f DEL 1-rc3 RET M-n M-n M-n
> C-c C-a M-p

Duh!  Now I see why I wasn't seeing your behavior.  Sorry for being a jerk.

Yes, indeed, there's a discrepency betwen the code and the doc.

The doc says "apply to new file, unless diff-jump-to-old-file says
otherwise".

The code does "apply forward to old file, or if prefix arg is given apply
backward to new file".

The code is as is it because it based on the assumption that either there
are 2 files and you're looking at the diff between the two (in which case
applying forward on the new file doesn't make sense and vice-versa), or
there's only one file so it doesn't matter.

Hmmm... I like the way the code works for my use, but it seems that it
doesn't work well in your case.

In your case, the patch specifies two files which diff-mode can both find,
yet, the patch is not between those two files (at least in your test case,
the two files are just the same, presumably one being a "working tree" and
the other being basically unrelated).
Is your test case very representative, or are there many other different
cases where you bump into the same problem?  If so, what does the "problem
in its most general description" look like?

Also, the fact that M-RET jumps to the exact opposite file from the one that
C-c C-a would apply to (i.e. with C-u it jumps to the new file and with it,
to the old), is ..hmm.. "unfortunate".


        Stefan