Unified Diff Format

A unified diff is composed of one or more hunks. Each hunk begins with a header line specifying the line ranges in the original and new file, formatted as @@ -old_start,old_count +new_start,new_count @@. The body of the hunk displays context lines (prefixed with a space), deletion lines (prefixed with -), and insertion lines (prefixed with +). This structure allows a patch to be applied even if the target file has shifted slightly, as the patch utility can locate the correct position using the surrounding context.

The format is designed to represent the shortest sequence of operations needed to transform File A into File B. Unlike a simple side-by-side view, a unified diff encodes an actionable script. The diff utility, often using the Myers algorithm, computes this minimal set of insertions and deletions. This compact representation is critical for efficient storage and transmission, reducing bandwidth in distributed version control systems like Git.

Despite being machine-parsable, the format is optimized for human review. The use of + and - prefixes creates an intuitive visual grammar. The inclusion of 3 lines of unchanged context above and below each change allows a reviewer to immediately understand the logical location of a modification without needing to open the full source file. This balance of compactness and clarity is why platforms like GitHub and GitLab render unified diffs as the primary code review interface.

A unified diff begins with metadata lines that identify the compared files. These lines use the format --- original_file and +++ new_file, often including a timestamp or revision hash. This header is essential for the patch program to identify the target file. In modern version control, this metadata is extended to include Git-specific headers like the index line, which records the blob hashes and file mode of the compared versions, ensuring cryptographic integrity of the change set.

The format explicitly handles a common edge case: a missing newline character at the end of a file. When a file lacks a terminating newline, the unified diff appends the line \ No newline at end of file to the relevant hunk. This is not a comment but a critical instruction that prevents the patch utility from incorrectly merging lines. Without this marker, applying a patch could inadvertently join two separate lines, corrupting the output.

The foundational O(ND) greedy algorithm that computes the shortest edit script between two sequences. It operates by exploring an edit graph where horizontal moves represent deletions and vertical moves represent insertions. This algorithm is the engine behind the standard Unix diff utility and directly generates the minimal set of changes output in Unified Diff Format. Its efficiency comes from avoiding the full O(N²) comparison space by only exploring the frontier of the shortest path.

A quantitative metric measuring the minimum number of single-character operations—insertions, deletions, or substitutions—required to transform one string into another. This concept underpins all diff algorithms. In the context of Unified Diff, line-level edit distance determines the minimal set of changed lines. Understanding this metric is crucial for evaluating diff quality: a lower edit distance generally indicates a more concise and accurate representation of the actual changes made.

A classic dynamic programming algorithm that identifies the longest sequence of lines appearing in the same order in both the original and modified documents. The LCS forms the backbone of the diff: lines not in the LCS are the ones reported as additions or deletions in the Unified Diff output. By maximizing the amount of unchanged context, the LCS approach ensures the resulting patch file is as compact and human-readable as possible.

A hunk is the fundamental unit of a Unified Diff, representing one contiguous region of change. Each hunk begins with a header specifying the line ranges in the original and modified files (e.g., @@ -10,7 +10,6 @@). The header is followed by context lines (prefixed with a space), deletion lines (-), and insertion lines (+). The standard three lines of unchanged context before and after changes provide human reviewers with the necessary surrounding logic to understand the modification.