If the input to patch contains multiple changes to a single file where a
later change modifies text which was also modified in an earlier change,
patch --dry-run will claim that the later change fails to apply even if
patch without --dry-run would have applied both changes successfully.
(This can occur when, for example, someone creates a single patch file
by concatenating multiple VCS commit diffs.)
Simple reproducer:
---------------- test.sh ----------------
cat >testdiff <<EOT
--- testfile 2026-09-07 18:16:17 +0900
+++ testfile 2026-09-07 18:16:20 +0900
@@ -1 +1 @@
-1
+2
--- testfile 2026-09-07 18:16:20 +0900
+++ testfile 2026-09-07 18:16:23 +0900
@@ -1 +1 @@
-2
+3
EOT
# patch (without --dry-run) succeeds as expected
echo >testfile 1
patch <testdiff || { echo >&2 "*** patch failed"; exit 1; }
# patch --dry-run unexpectedly fails on the same input
echo >testfile 1
patch --dry-run <testdiff || { echo >&2 "*** patch --dry-run failed"; exit 1; }
-----------------------------------------
$ sh test.sh
patching file testfile
patching file testfile
checking file testfile
checking file testfile
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED
*** patch --dry-run failed
$ patch --version
GNU patch 2.8
Based on the thread at
<https://lists.gnu.org/archive/html/bug-patch/2010-09/msg00000.html>
(which I grant is now somewhat in the past), I take it that not
supporting multiple changes to the same file in the same input is
considered a design limitation rather than a bug. However, the
documentation for --dry-run suggests to a user unfamiliar with that
discussion that patch with --dry-run behaves exactly the same as without
in all respects other than not modifying files, so if this will not be
fixed, I would suggest documenting that limitation in the man page and
info file.
--Andrew Church
https://achurch.org/
(note that I am not subscribed to the list)
