Andreas,
Op 4-09-2017 om 14:15 schreef Andreas Grünbacher:
I'm getting the following result with current patch, which differs from what you are getting: $ patch -i goes-wrong.patch -o testor.c.out testor.c patching file testor.c.out (read from testor.c) Hunk #1 succeeded at 7 with fuzz 1. Hunk #2 succeeded at 56 with fuzz 2 (offset 8 lines).
That is what I get when I apply the patch a second time. I'm pretty sure your testor.c file has already been patched/modified -- because if not, and the first hunk applies with fuzz 1, the second one should apply with no fuzz and offset 0 lines. The offset of 8 lines means that already two hunks of 4 lines have been inserted. The original testor.c has this: $ wc testor.c 95 388 2719 testor.c
The algorithm patch uses for matching hunks is rather crude: it tries to match a hunk anywhere in the file with fuzz 0, then with fuzz 1, etc. When a hunk matches, it is applied and the remaining hunks are matched against the rest of the file (that is, the second hunk will not be applied before the first one). There is no global optimization of fuzz or anything like that. When a patch applies with fuzz, it is best to check the result rather than relying on patch to do the right thing. Apart from fixing bugs, we cannot easily change this behavior: people have come to expect patch to behave the way it does.
I know. I was merely "philosophying". :) Benno
