Tom, 2016-08-26 6:17 GMT+02:00 Tom Hale <t...@hale.ee>: > Bruno wrote to me and asked a very good question: > > On 2016-08-26 00:53, Bruno Haible wrote: >>> >>> I'm of making a pull request that allows patch to exit(0) when all >>> rejected hunks are already applied. >>> >>> This will allow idempotent patching, ie, patch to return 0 when a patch >>> has already been applied. >> >> >> How does your proposal differ from the -N / --forward option? > > > I hoped that -N would do the trick for me too, but there is a limitation of > -N: > > The current (git repository) manual says: > "When a patch does not apply, patch usually checks if the patch looks like > it has been reversed. The --forward option prevents that." > > Version 2.7.1 said (in worse English but giving far more insight the code's > behaviour): > "Ignore patches that seem to be reversed or already applied. It is only > checked if the first hunk of a patch can be reversed. ..."
I'm tempted to change that to: "When a patch does not apply, patch usually checks if the patch looks like it has been reversed (by trying to reverse-apply the first hunk)." > In the case of a some previously applied hunks, the current git code with > "-N" will create a ".rej" file and exit(1). > > Perhaps better than `-z' would be: > -s Skip hunks already applied > > Would the maintainers accept a pull request for this? > > There's no way I'm aware of to have patch skip hunks which have already been > applied. > > Here's a demonstration of the current limitation: > > +ravi@boxy:~/tmp/patch-test$ cat numbers > 1 > 2 > 3 > 4 > 5 > 6 > 7 > +ravi@boxy:~/tmp/patch-test$ cat num-1-7 > one > 2 > 3 > 4 > 5 > 6 > seven > +ravi@boxy:~/tmp/patch-test$ cat num-1-4-7 > one > 2 > 3 > four > 5 > 6 > seven > +ravi@boxy:~/tmp/patch-test$ diff -u2 numbers num-1-7 > 1-7 > +ravi@boxy:~/tmp/patch-test[1]$ diff -u2 numbers num-1-4-7 > 1-4-7 > +ravi@boxy:~/tmp/patch-test[1]$ cat 1-7 > --- numbers 2016-08-26 10:36:17.848926420 +0700 > +++ num-1-7 2016-08-26 10:15:21.167754859 +0700 > @@ -1,3 +1,3 @@ > -1 > +one > 2 > 3 > @@ -5,3 +5,3 @@ > 5 > 6 > -7 > +seven > +ravi@boxy:~/tmp/patch-test$ cat 1-4-7 > --- numbers 2016-08-26 10:36:17.848926420 +0700 > +++ num-1-4-7 2016-08-26 10:15:11.175572637 +0700 > @@ -1,7 +1,7 @@ > -1 > +one > 2 > 3 > -4 > +four > 5 > 6 > -7 > +seven > +ravi@boxy:~/tmp/patch-test$ patch numbers -i 1-7 > patching file numbers > +ravi@boxy:~/tmp/patch-test$ patch numbers -Ni 1-4-7 > patching file numbers > Hunk #1 FAILED at 1. > 1 out of 1 hunk FAILED -- saving rejects to file numbers.rej > +ravi@boxy:~/tmp/patch-test[1]$ cat numbers.rej > --- numbers 2016-08-26 10:36:17.848926420 +0700 > +++ num-1-4-7 2016-08-26 10:15:11.175572637 +0700 > @@ -1,7 +1,7 @@ > -1 > +one > 2 > 3 > -4 > +four > 5 > 6 > -7 > +seven > +ravi@boxy:~/tmp/patch-test$ IMO it would make more sense to improve the --merge option to work better. Merge is supposed to produce a result similar to "diff3 --merge" or git merge as far as that is possible with the context information contained in the patch. This includes recognizing changes which are already applied, and splitting of large hunks. Splitting of large hunks is important here and for recognizing already-applied changes because patch would otherwise produce worse results the more lines of context a patch has. In the above example: $ patch numbers --merge < 1-4-7 patching file numbers Hunk #1 already applied at 1, merged at 4, NOT MERGED at 8-11. So it turns out that --merge fails to recognize that the last change (from 7 to seven) has already been applied. That's a bug which should be fixed, and the example should be added as a test case. I'm also aware of the following additional --merge bug which hasn't received a fix, yet: http://savannah.gnu.org/bugs/?42922 Thanks, Andreas
