File.OldName and File.NewName are the same when they shouldn't be

[ghostsquad]

I have a patch that looks like this:

diff -u /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-1/cluster-1.yaml /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-2/cluster-1.yaml
--- /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-1/cluster-1.yaml	2026-01-14 20:44:05
+++ /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-2/cluster-1.yaml	2026-01-14 20:44:05
@@ -11,7 +11,7 @@
     app.kubernetes.io/version: "6.9.4"
     app.kubernetes.io/managed-by: Helm
   annotations:
-    specific: cluster-1
+    specific: cluster-1-new
 spec:
   type: ClusterIP
   ports:
diff -u /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-1/cluster-2.yaml /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-2/cluster-2.yaml
--- /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-1/cluster-2.yaml	2026-01-14 20:44:05
+++ /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-2/cluster-2.yaml	2026-01-14 20:44:05
@@ -11,7 +11,7 @@
     app.kubernetes.io/version: "6.9.4"
     app.kubernetes.io/managed-by: Helm
   annotations:
-    specific: cluster-2
+    specific: cluster-2-new
 spec:
   type: ClusterIP
   ports:
diff -u /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-1/cluster-3.yaml /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-2/cluster-3.yaml
--- /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-1/cluster-3.yaml	2026-01-14 20:44:05
+++ /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-2/cluster-3.yaml	2026-01-14 20:44:05
@@ -11,7 +11,7 @@
     app.kubernetes.io/version: "6.9.4"
     app.kubernetes.io/managed-by: Helm
   annotations:
-    specific: cluster-3
+    specific: cluster-3-special
 spec:
   type: ClusterIP
   ports:
diff -u /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-1/cluster-4.yaml /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-2/cluster-4.yaml
--- /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-1/cluster-4.yaml	2026-01-14 20:44:05
+++ /Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-2/cluster-4.yaml	2026-01-14 20:44:06
@@ -11,7 +11,7 @@
     app.kubernetes.io/version: "6.9.4"
     app.kubernetes.io/managed-by: Helm
   annotations:
-    specific: cluster-4
+    specific: cluster-4-new
 spec:
   type: ClusterIP
   ports:

When I parse this, and look at each OldName and NewName, I expect to see .../rendered-1/... as the old, and .../rendered-2/... as the new (shortened for brevity), but both OldName and NewName show up as rendered-2.

files, _, err := gitdiff.Parse(patchFile)
for _, file := range files {
	godump.Dump("oldName", file.OldName)
	godump.Dump("newName", file.NewName)
}

<#dump // cmd/diff-differ/main.go:57
"oldName" #string
"/Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-2/cluster-1.yaml" #string
<#dump // cmd/diff-differ/main.go:58
"newName" #string
"/Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-2/cluster-1.yaml" #string
<#dump // cmd/diff-differ/main.go:57
"oldName" #string
"/Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-2/cluster-2.yaml" #string
<#dump // cmd/diff-differ/main.go:58
"newName" #string
"/Users/ghostsquad/projects/diff-differ/docs/examples/k8s-manifests/rendered-2/cluster-2.yaml" #string

This looks like a bug.

[bluekeyes]

This is intentional, in that it matches how Git processes unified/traditional patches. In that context, Git is attempting to find the single file to which it should apply the patch content, and it uses the new name, subject to a heuristic about taking the shorter name when one is a prefix of the other. Traditional patches can't encode copy or rename operations in the same way that Git's patch format can, so these patches are assumed to always be modification, additions, or deletions. In Git's model, these three types apply to a single file with one name, so either exactly one of OldName and NewName is set (delete/add) or both are set to the same value (modify).

Looking at it now, I can see an argument that this is not desirable behavior in this library. Since applying a patch requires the caller to do all file matching, there's no real reason the library has to force this when parsing the patch, especially for traditional patches which aren't as well-defined as Git's. I'll think about this more to make sure I'm not missing anything, but will consider changing the behavior so that the parsed output is closer to the literal input of the patch in this case.