Unified Diff - Single Hunk, Single File
One added guard line in a shell script, rendered as a POSIX `diff -u` with three lines of context and timestamped ---/+++ headers. The smallest complete unified diff, and the baseline the context-format and normal-format twins in this group encode identically.
--- a/scripts/release.sh 2026-03-02 09:14:03.000000000 +0000
+++ b/scripts/release.sh 2026-03-02 10:41:55.000000000 +0000
@@ -1,4 +1,5 @@
#!/bin/sh
set -eu
VERSION="$1"
+test -n "$VERSION" || { echo "usage: release.sh <version>" >&2; exit 2; }
echo "tagging $VERSION"
Specifications
- Seed
- 20260807
- Diff Format
- unified
- Context
- 3
- Files
- 1
- Hunks
- 1
- Insertions
- 1
- Deletions
- 0
- Line Endings
- LF
- Encoding
- UTF-8
Testing contract
Expected to pass- Scenario
- Parse a minimal unified diff and apply it to the documented before-state of scripts/release.sh.
- Expected result
- One hunk at @@ -3,3 +3,4 @@ inserting a single line; 1 insertion, 0 deletions, 1 file changed.
What is a .diff file?
A .diff file records the difference between two versions of one or more text files. The unified format — the default almost everywhere — names the old and new files on `---` and `+++` lines, then lists hunks introduced by `@@ -old,count +new,count @@` in which context lines are unprefixed and changed lines are prefixed with `-` or `+`. Older context and normal diff formats exist but are rarely produced today.
How to use this file
Use an example .diff file to test diff parsers, syntax highlighters, and merge tooling — verifying hunk-offset arithmetic, correct handling of context lines that begin with a space, and behaviour on files whose changes include trailing-whitespace or line-ending differences.
How to use this file for testing
“Unified Diff - Single Hunk, Single File” is a deterministic Novus Examples fixture for Visual diff / regression, Code parsing, Editor testing. A/B image twins with controlled pixel changes, anti-alias variants, and UI chrome crops for screenshot diff and visual regression tools.
Documented properties for this file: seed 20260807 · UTF-8 · LF. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Diff and patch fixtures name their target paths and the exact edge case they exercise — rename, mode change, binary hunk, CRLF↔LF, or missing trailing newline. Apply or render them against the documented before-state; every author, path, and hash is fictional.
Treat A/B twins as a visual regression unit: run your pixel or perceptual diff, assert a non-zero delta on the changed twin, and keep thresholds calibrated against the documented change kind in specs.
Related files
- diffUnified Diff - Bare Line Number in the Hunk HeaderA one-line file changed in place. Both ranges have length one, so the header is written `@@ -1 +1 @@` with no comma and no count — the abbreviation the unified format allows and that regexes of the form `-(\d+),(\d+)` fail to match.
- diffUnified Diff - Deleted File Against /dev/nullThe mirror of the added-file fixture: every line is a deletion and the new range is `+0,0`. A renderer that writes an empty file instead of unlinking it, or that reports the change as a truncation, fails this one.
- diffUnified Diff - Function Heading After the Hunk Headergit appends the enclosing declaration after the closing `@@` of each hunk header. The text is free-form and is not part of the range, so a parser that splits the header on `@@` and takes the last field reads the function signature as a range.
- diffUnified Diff - New File Against /dev/nullA file created from nothing: the old side is `/dev/null` and the hunk header carries the zero-length range `-0,0`. Parsers that compute a 1-based start line from the old range produce line 1 instead of line 0 unless they special-case a zero count.
- diffUnified Diff - No Newline Marker on Both SidesNeither version ends with a newline, so the marker appears twice in one hunk: once after the last removed line and once after the last added line. Parsers that treat the marker as a terminator rather than an annotation stop reading at the first one and lose the added line.
- diffUnified Diff - No Newline Marker on the New Side OnlyA one-line file is edited and loses its trailing newline in the process, so the marker follows the `+` line instead of the `-` line. Applying this and then re-diffing must not reintroduce the newline.
Generated by generation/version_control.py. Free for any use, no attribution required — license.