Combined Diff - Octopus Merge With Three Parents
An octopus merge, so the hunk marker grows to `@@@@` and every line carries three prefix columns. Any parser that hard-codes `@@@` or assumes two columns reads the third column as the first character of the line's content.
diff --cc config/service.yaml
index 37ff471,8bf23d2,b54d2a5..808a726
--- a/config/service.yaml
+++ b/config/service.yaml
@@@@ -1,4 -1,4 -1,4 +1,4 @@@@
service: ledger
-timeout: 30
- timeout: 45
++timeout: 60
jitter: on
-- backoff: linear
++ backoff: exponential
Specifications
- Seed
- 20260807
- Diff Format
- combined
- Parents
- 3
- Hunk Marker
- @@@@
- Prefix Columns
- 3
- Index Blobs
- 4
- Line Endings
- LF
- Encoding
- UTF-8
Testing contract
Expected to pass- Scenario
- Parse a combined diff whose parent count is not two.
- Expected result
- The column count is derived from the number of @ characters (4 means 3 parents); every content line is split after exactly 3 prefix characters.
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
“Combined Diff - Octopus Merge With Three Parents” is a deterministic Novus Examples fixture for Error handling, Visual diff / regression, Code parsing. Deliberately corrupt and invalid files, clearly labelled, for testing how your tool fails.
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.
Related files
- txtMerge Conflict - diff3 Marker Style With Base SectionThe same conflict with `merge.conflictStyle=diff3`, which inserts the merge base between the two sides behind a row of pipes. Tools that split a conflict on `=======` alone silently fold the ancestor text into the ours side.
- txtMerge Conflict - Nested Markers From a Conflicted ResolutionSomeone committed a file that still contained conflict markers, and merging that commit produced markers inside markers. Region matchers that pair the first `<<<<<<<` with the first `=======` split this file in the wrong place and produce two overlapping regions that cannot both be resolved.
- mdMerge Conflict - Real Region Beside Marker LookalikesDocumentation about merge conflicts that quotes the markers inside a fenced code block, and then genuinely conflicts further down. A pre-commit hook that greps for `^<<<<<<<` reports two hits and blocks a clean commit; one that understands Markdown fences reports the one that matters.
- txtMerge Conflict - Three Regions in One FileOne file left with three independent unresolved regions and clean text between them, which is what a real deployment-values merge looks like. Editors that jump to 'the next conflict' and resolvers that report a boolean rather than a count both get exercised here.
- txtMerge Conflict - Two-Way (merge) Marker StyleA working-tree file left mid-merge in git's default `merge` conflict style: our version, a row of equals signs, their version, and branch labels on the opening and closing markers. Both sides happen to end with the same line, which the zdiff3 twin in this group hoists out and this style repeats.
- txtMerge Conflict - zdiff3 Marker StyleThe identical merge under `merge.conflictStyle=zdiff3`, which hoists lines common to both sides out of the conflict region — here 'jitter: on' moves below the closing marker. Diff this against the diff3 twin to see that the same conflict produces different file contents depending on one config value.
Generated by generation/version_control.py. Free for any use, no attribution required — license.