GeezerVison

Problem

UnifiedDiffUtils.generateUnifiedDiff treats any single-delta patch with a null original file name as a newly created file. The new-file flag reaches processDeltas, which then hardcodes the hunk start of the original side to 0 regardless of where the delta is. For a patch that replaces or deletes lines this writes a header naming a line that does not exist.

Reproduction (public API only, no context lines):

List<String> original = Arrays.asList("a", "b", "c");
List<String> revised  = Arrays.asList("a", "x", "c");
Patch<String> patch = DiffUtils.diff(original, revised);

UnifiedDiffUtils.generateUnifiedDiff(null, "revised", original, patch, 0)
        .forEach(System.out::println);

Actual output:

--- /dev/null
+++ revised
@@ -0,1 +2,1 @@
-b
+x

diff -U0 and git diff -U0 write @@ -2,1 +2,1 @@ for the same change:

$ git diff --no-index --no-color -U0 -- a.txt b.txt
--- a/a.txt
+++ b/b.txt
@@ -2 +2 @@
-b
+x

(difflib.unified_diff(..., n=0) produces @@ -2 +2 @@ as well.)

The damage is not only cosmetic. parseUnifiedDiff applies the library's own "an empty range names the line before it" rule to the 0 and produces a ChangeDelta at position 0 instead of position 1, so the generated diff no longer applies to the file it was generated from:

• replacing or deleting a line → PatchFailedException: could not apply patch due to CONTENT_DOES_NOT_MATCH_TARGET
• pure insertion → applies silently at the wrong place, e.g. [a, b, c] -> [a, b, c, x] generated with a null name applies as [x, a, b, c]

Appending with one line of context, or using two or more deltas, numbers correctly — the bug is specific to a lone delta whose source side is not empty.

Fix

java-diff-utils/src/main/java/com/github/difflib/UnifiedDiffUtils.java:196

The new-file handling is now restricted to patches whose source chunk is empty, which is what actually distinguishes "created this file" from "renamed/no original name given":

patchDeltas.size() == 1 && originalFileName == null && delta.getSource().size() == 0

A genuine new file (empty original, null name) still emits @@ -0,0 +1,N @@, unchanged. Patches with two or more deltas are untouched.

Tests

GenerateUnifiedDiffTest.testSingleDeltaWithNullOriginalNameKeepsOriginalLineNumbers asserts the header, the body and — importantly — that the generated diff still parses back and applies to the original.

Run with the unmodified baseline (git stash of the one-line source change, test kept):

[ERROR] GenerateUnifiedDiffTest.testSingleDeltaWithNullOriginalNameKeepsOriginalLineNumbers:168
        expected: <@@ -2,1 +2,1 @@> but was: <@@ -0,1 +2,1 @@>
[ERROR] Tests run: 14, Failures: 1, Errors: 0

With the fix (the whole reactor, mvn -B package on JDK 17):

[INFO] Tests run: 169, Failures: 0, Errors: 0, Skipped: 3      (core module)
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0        (java-diff-utils-jgit)
[INFO] BUILD SUCCESS

The 3 skipped tests are skipped on master as well. Spotless (palantirJavaFormat, bound to validate) is applied to the changed files.

Note

UnifiedDiffWriter.processDeltas carries the same patchDeltas.size() == 1 && file.getFromFile() == null condition, so a UnifiedDiffFile whose fromFile is null has the same numbering problem. I left that out of this change to keep it to one subject — happy to follow up separately if you want both sides fixed.