There are patches that should be applied in a strict order to be successful (ie., on a set of files, apply patch#1 first, then apply patch#2 on the result yielded by applying patch#1). I concatenate the patches (in correct order), and pipe them to patch(1). But, as always, I check what would happen if the patches were applied (use the -C option). The test run can show wrong results if the concatenated patch references a file multiple times near a common line, probably because in the check-only mode, patch(1) tries to apply each hunk on the original, unmodified files.
(If this won't be fixed soon, it would be nice to have this documented in the manpages.)
How-To-Repeat: diff -u orig mod1 > mod1.patch # mod1 changes line N of orig
diff -u orig mod2 > mod2.patch # mod2 changes line N of orig, too !
cat mod1.patch mod2.patch | patch -Cs # looks OK
cat mod1.patch mod2.patch | patch -s # fail !
let me be more concise:
put words.txt and con.patch in one directory, cd to that directory, then:
# cat con.patch | patch -p1 -Cs
the test run says that the patch looks OK (applies cleanly), so we
proceed with actual patching:
# cat con.patch | patch -p1 -C
but the patch actually fails, so the test run lied !
i've just noticed that in my 2nd message i've screwed up the command
flags. restating everything:
put words.txt and con.patch in one directory, cd to that directory, and then do:
$ cat con.patch | patch -sp1 --check
the --check flag means "do not actually edit files, just check to see
what would happen". the above test run says that the patch applies
cleanly. now do:
$ cat con.patch | patch -sp1
notice that now the patch actually fails, so the test run lied.
For bugs matching the following criteria:
Status: In Progress Changed: (is less than) 2014-06-01
Reset to default assignee and clear in-progress tags.
Mail being skipped