Short, known-correct source files in many languages with classes, functions, generics, enums, and error handling — for testing parsers, linters, formatters, language detection, and diff viewers.
The classic hello-world in idiomatic Python 3, with a shebang, a module docstring, and the standard main guard — the minimal correct program for testing highlighters and interpreters.
A realistic Python snippet exercising type hints, an lru_cache-memoised recursive function, a generator, and a frozen dataclass — for testing syntax highlighters, linters (ruff/flake8), and formatters (black).
The classic hello-world in modern JavaScript — a minimal function calling console.log, for testing highlighters, Node, and JS parsers.
A realistic JavaScript snippet with an ES class, private #fields, arrow functions, template literals, a getter, and async/await — for testing highlighters, ESLint, Prettier, and bundlers.
The classic hello-world in TypeScript (shipped as .mts to avoid the MPEG-TS .ts collision) — a typed function for testing TypeScript-aware highlighters and the tsc compiler.
A realistic TypeScript snippet with an enum, a discriminated union, generics, exhaustive switch handling, and a typed reduce — for testing the type checker, highlighters, and the TS ESLint parser.
A minimal, valid HTML5 document — doctype, head, and a single heading — for testing HTML parsers, highlighters, and validators against the simplest well-formed page.
A realistic semantic HTML page with landmark elements (header, nav, main, article, footer), a figure with alt text and caption, and lists — for testing HTML parsers, accessibility tooling, and highlighters.
A minimal stylesheet that centres a heading with grid — the simplest useful CSS file for testing highlighters, CSS parsers, and minifiers.
A realistic component stylesheet using custom properties, flexbox, a fluid clamp() font size, color-mix(), a keyframe animation, and a media query — for testing CSS parsers, linters (stylelint), and highlighters.
The classic hello-world in Java — a public class with the standard main method — for testing highlighters, javac, and Java parsers.
A realistic Java class with a package declaration, fields, a nested record, methods that throw exceptions, and formatted output — for testing highlighters, javac, Checkstyle, and parsers.
The classic hello-world in C — an include, main, and printf — for testing highlighters, C compilers, and parsers against the canonical first program.
A realistic C program: a singly linked list with a typedef struct, malloc/free memory management, pointer walking, and error handling — for testing highlighters, compilers, and static analysers.
The classic hello-world in C++ — iostream and std::cout — for testing highlighters, C++ compilers, and parsers.
A realistic C++ snippet with a class template, STL algorithms (max_element, accumulate), std::move, and range handling — for testing highlighters, g++/clang++, and parsers against real templates.
The classic hello-world in Go — package main, an import, and fmt.Println, tab-indented like gofmt — for testing highlighters, the Go compiler, and parsers.
A realistic Go program: a worker pool with structs and methods, goroutines, buffered channels, and a sync.WaitGroup — tab-indented like gofmt, for testing highlighters, go vet, and parsers.
The classic hello-world in Rust — fn main and the println! macro — for testing highlighters, rustc, and parsers.
A realistic Rust snippet with an enum carrying data, a trait and impl, exhaustive match, iterators, and Option handling — for testing highlighters, rustc, clippy, and parsers against real ownership-era code.
The classic hello-world in PHP — an opening tag and echo — for testing highlighters, the PHP interpreter, and parsers.
A realistic modern-PHP snippet with strict types, a namespace, a backed enum, a final class with constructor-promoted readonly properties, and array_reduce with an arrow function — for testing highlighters, PHPStan, and parsers.
The classic hello-world in Ruby — a single puts — for testing highlighters, the Ruby interpreter, and parsers.
A realistic Ruby snippet: a Stack class that mixes in Enumerable, yields blocks, raises a custom error class, and uses string interpolation and symbol-to-proc — for testing highlighters, RuboCop, and parsers.
The classic hello-world in Bash — a shebang and echo, with LF line endings so it runs on Unix — for testing highlighters, ShellCheck, and shell parsers.
A realistic Bash script using strict mode (set -euo pipefail), functions, default parameters, a loop, and conditionals — an illustrative fixture (review before running) for testing highlighters, ShellCheck, and shfmt.
The classic first query in SQL — a single SELECT of a literal — for testing highlighters, SQL parsers, and query editors.
A realistic SQL script with CREATE TABLE constraints and foreign keys, INSERT seed data, a CREATE VIEW, and a grouped aggregate query with a join — for testing SQL parsers, formatters, and highlighters.
The classic hello-world in Kotlin — a top-level main function — for testing highlighters, the Kotlin compiler, and parsers.
A realistic Kotlin snippet with data classes, an enum, a sealed result interface, extension functions, and when expressions — for testing highlighters, the Kotlin compiler, ktlint, and parsers.
The classic hello-world in Swift — a single print — for testing highlighters, the Swift compiler, and parsers.
A realistic Swift snippet with an enum, a protocol, a struct with a computed property, optionals and optional binding, and higher-order functions — for testing highlighters, the Swift compiler, SwiftLint, and parsers.
Idiomatic C# hello-world for syntax highlighters and Roslyn-style parsers.
A small C# iterator Fibonacci utility — realistic snippet for language tooling.
Minimal Dart hello-world for Flutter/Dart IDE and highlight tests.
Tiny Dart class with a counter — fixture for Dart analysis servers.
Elixir module hello — for Beam/Elixir syntax and formatter smoke tests.
Elixir pipe-operator snippet for AST and formatter fixtures.
Zig hello-world for Zig language-server and highlighter tests.
Zig function plus a unit test stub — realistic small module.
Scala 3-style object hello for Scalac / Metals fixtures.
Scala foldLeft snippet for syntax and indexer tests.
Intentionally invalid Python indentation for linter / parser error-path tests. Labelled intentionally invalid in title and description.
Intentionally corrupt JavaScript object literal — labelled invalid for error handling. Labelled intentionally invalid in title and description.
Intentionally invalid JSON (unquoted key + trailing) for strict parser failure tests. Labelled intentionally invalid in title and description.
Intentionally invalid YAML indentation for parser error fixtures. Labelled intentionally invalid in title and description.
Minimal Julia hello-world for syntax highlighters and Julia LSP smoke tests.
Julia typed Fibonacci with a for-loop — realistic snippet for language tooling.
Julia broadcast operators (.^ .+ ) for highlighter and parser edge cases.
Idiomatic Haskell hello-world for GHC / HLS fixtures.
Haskell foldl snippet for AST and highlighter tests.
Haskell Maybe pattern matching — realistic small module.
Minimal Lua hello for embedder and syntax-highlight tests.
Lua table with method colon syntax for parsers.
Tiny Lua coroutine yield loop for language tooling.
Minimal R hello-world for RStudio / language-server fixtures.
R data.frame construction — realistic snippet for R parsers.
R native pipe (|>) snippet for modern R tooling.
Minimal Clojure hello for CIDER / clj-kondo fixtures.
Clojure reduce utility — realistic snippet.
Clojure thread-first macro for highlighter tests.
Minimal Fortran 90 hello for gfortran / highlighter fixtures.
Fortran do-loop sum — realistic numerical snippet.
Fortran module with a pure-ish helper for module parsers.
Minimal Nim hello for nimlsp / highlighter tests.
Nim recursive fib proc — realistic snippet.
Nim object type plus proc — for Nim AST tooling.
Python dataclass SAMPLE for highlighter and type-checker smoke tests.
Tiny asyncio gather stub for async Python tooling.
Go generics helper for gopls / highlighter fixtures.
Rust Result map chain — realistic error-handling snippet.
TypeScript satisfies operator sample (.mts) for TS tooling.
Java record type hello for javac / highlighter fixtures.
Kotlin data class SAMPLE for Kotlin language-server tests.
Swift struct SAMPLE for SourceKit fixtures.
Ruby nested module SAMPLE for parser tests.
PHP 8 attributes SAMPLE for PHP tooling.
C struct SAMPLE for clangd / highlighter fixtures.
C++17 optional SAMPLE for clangd fixtures.
Bash strict-mode hello for shellcheck / highlighter tests.
SQL window function SAMPLE for SQL parsers.
C# LINQ chain SAMPLE for Roslyn fixtures.
Scala pattern match SAMPLE for Metals fixtures.
Zig errdefer SAMPLE for Zig language-server tests.
Dart async Future SAMPLE for analysis-server tests.
Elixir GenServer stub SAMPLE for Beam tooling.
Intentionally invalid Julia (unclosed function) for linter error-path tests.
Intentionally invalid Haskell (unterminated string) for parser failure tests.
Intentionally invalid Lua table for error handling.
Intentionally invalid R (unclosed call) for parser tests.
Intentionally invalid Clojure (unbalanced forms) for clj-kondo-style tests.
Intentionally invalid Fortran for compiler error fixtures.
Intentionally invalid Nim for nim check error paths.
Intentionally invalid Go syntax for gofmt/parser failure tests.
Intentionally invalid Rust for rustc error-path fixtures.
Intentionally invalid Python match (missing colon) for linters.
Tiny multi-language SAMPLE monorepo ZIP (web/api/util/scripts) for unpack-then-lint and monorepo tooling.
Julia Macro SAMPLE for Wave G language-tooling coverage.
Haskell Typeclass SAMPLE for Wave G language-tooling coverage.
Lua Metatable SAMPLE for Wave G language-tooling coverage.
Nim Template SAMPLE for Wave G language-tooling coverage.
Tiny SAMPLE SQL shape (select-star-invalid) for static-analysis demos — not live DDL.
Tiny SAMPLE SQL shape (missing-where-update) for static-analysis demos — not live DDL.
Tiny SAMPLE SQL shape (order-by-injection-shape) for static-analysis demos — not live DDL.
Tiny SAMPLE SQL shape (implicit-cross-join) for static-analysis demos — not live DDL.
Tiny SAMPLE SQL shape (drop-table-comment) for static-analysis demos — not live DDL.
Tiny SAMPLE SQL shape (union-all-dupes) for static-analysis demos — not live DDL.
Tiny SAMPLE tooling config snippet (docker-compose-snippet) for editor/linter harnesses.
Tiny SAMPLE tooling config snippet (github-actions-snippet) for editor/linter harnesses.
Tiny SAMPLE tooling config snippet (eslint-flat-snippet) for editor/linter harnesses.
Tiny SAMPLE tooling config snippet (prettier-config) for editor/linter harnesses.
Tiny SAMPLE tooling config snippet (editorconfig-snippet) for editor/linter harnesses.
Tiny SAMPLE tooling config snippet (tsconfig-strict-snippet) for editor/linter harnesses.
Intentionally lint-bait SAMPLE python snippet (unused-import-invalid) for rule-engine tests.
Intentionally lint-bait SAMPLE python snippet (bare-except-invalid) for rule-engine tests.
Intentionally lint-bait SAMPLE javascript snippet (var-shadow-invalid) for rule-engine tests.
Intentionally lint-bait SAMPLE javascript snippet (eqeqeq-invalid) for rule-engine tests.
Intentionally lint-bait SAMPLE typescript snippet (any-cast-invalid) for rule-engine tests.
Intentionally lint-bait SAMPLE go snippet (errcheck-invalid) for rule-engine tests.
Intentionally lint-bait SAMPLE rust snippet (unwrap-invalid) for rule-engine tests.
Intentionally lint-bait SAMPLE java snippet (empty-catch-invalid) for rule-engine tests.
Intentionally lint-bait SAMPLE ruby snippet (rescue-all-invalid) for rule-engine tests.
Intentionally lint-bait SAMPLE php snippet (error-suppression-invalid) for rule-engine tests.
Intentionally lint-bait SAMPLE shell snippet (unquoted-var-invalid) for rule-engine tests.
Intentionally lint-bait SAMPLE csharp snippet (empty-catch-invalid) for rule-engine tests.
A one-line minified bundle built from two ES modules, ending in the `//# sourceMappingURL=` comment that points at the v3 map shipped beside it. For testing that a debugger, error reporter or bundler analyser follows the annotation and resolves the map relative to the bundle.
A complete v3 source map for the minified bundle: two sources with their full original text inlined in sourcesContent, two names, and five VLQ-encoded mapping segments. For testing source-map decoders and stack-trace symbolication without any network fetch of the originals.
The same v3 map with the sourcesContent array removed, which is how most production builds ship: the mappings resolve but the original text has to be fetched from the paths in `sources`. For testing the fallback path of a debugger when originals are unavailable.
The same bundle with its v3 map embedded as a base64 data: URI in the sourceMappingURL comment - the single-file form dev builds emit. For testing that a tool decodes an inline map instead of trying to fetch it as a relative path.
An index map: instead of a top-level `mappings` string it carries a `sections` array of offset-and-map pairs, the form used when several independently built chunks are concatenated. For testing decoders that assume every map has mappings at the root.
A minified stylesheet closing with the CSS form of the annotation, `/*# sourceMappingURL= */` - the comment syntax differs from JavaScript's and is a common reason a CSS map is silently ignored. For testing stylesheet source-map resolution.
The v3 map for the minified stylesheet: one source with its text inlined, an empty names array, and three segments covering the selector and both declarations. For testing that a decoder handles maps with no names at all.
A v3 map that resolves its sources through a `sourceRoot` scheme URL, uses `../` relative paths, leaves one sourcesContent entry null, and marks the second source as third-party via x_google_ignoreList. For testing URL joining and ignore-list support in a debugger.
Three suites under a <testsuites> root whose own attributes already hold the aggregate totals. A parser that sums the children and also trusts the root double-counts every case, which is the classic cause of a dashboard reporting 24 tests for a 12-test run.
The single-suite form Gradle and Ant write: the root element is <testsuite> with no <testsuites> wrapper at all. Parsers hardcoded to descend from <testsuites> read this file as empty rather than failing, so it silently reports a run of zero tests.
A report from a runner that never records durations: neither the suite nor any case carries a time attribute. Dashboards that parse time unconditionally throw here, and ones that default it to zero quietly report a suite that took no time at all.
The same classname and name appear twice with different outcomes — what a parameterised runner or a merged report can produce. Any store keyed on classname+name overwrites the first result and reports the suite as green or red depending purely on document order.
Cases annotated with the source file and line they were declared on, as pytest and several JS runners emit. This is what a code-review annotation bot needs to place a failure comment on the right line of the right file.
The reference LCOV tracefile: one record per source file with FN/FNDA function records, real BRDA branch records (block, branch and taken count, with '-' for a branch never reached) and DA line hits, closed by the LF/LH, FNF/FNH and BRF/BRH counters. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.
The Cobertura serialisation of the same run, with packages, classes, per-method line rates and condition-coverage attributes on every branching line. Cobertura expresses coverage as rates rather than counts, so this is the file that catches converters rounding a percentage into a hit count. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.
The JaCoCo serialisation, which reports missed/covered pairs rather than found/hit and adds INSTRUCTION and COMPLEXITY counters no other format carries. Converters routinely swap missed for covered here, which inverts the whole report. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.
The Clover serialisation, whose <metrics> element rolls statements, conditionals and methods into a single elements/coveredelements pair. Anything reading only that pair reports a blended percentage that matches none of the other three formats unless the components are separated first. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.
The raw Istanbul document nyc and Jest write before any reporter runs: statementMap, fnMap and branchMap giving source locations, with the s, f and b objects holding the hit counts. Branch counts here are arrays per branch point, which is why converting to LCOV doubles the branch total if the array is not flattened. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.
The same tracefile with every BRDA, BRF and BRH line removed — what a runner emits when branch instrumentation is off. A gate that reads branch coverage from this file must report it as unavailable, not as 0%, or an unconfigured project looks like a badly tested one.
Records containing FN/FNDA/FNF/FNH and nothing else: no DA lines, no LF or LH. Merge tools that assume every record ends with LF/LH either crash here or invent a zero line count for a file that simply was not line-instrumented.
Two TN: blocks — a unit run and an integration run — each carrying a full record for the same two source files. A correct merge sums the DA hit counts per line and recomputes LH; a tool that keeps the last record seen throws away the unit run entirely.
Every instrumented line present with a hit count of zero — the shape of a report from a run in which the tests never loaded the instrumented code. It is not an empty file, and conflating the two hides a broken test harness behind a missing-report warning.
Every line hit at least once, so LH equals LF exactly. The upper-bound control for a coverage gate, and the case that catches percentage formatting that renders 100% as 100.0% or, worse, rounds 99.95% up to it.
Three named test runs in one tracefile, each covering a different part of the tree, reported via the TN: record most tools quietly discard. Keeping the name is what lets a report answer which suite covered a given line.
Cobertura with a condition-coverage attribute on every branching line, written in the "50% (1/2)" form. The percentage and the fraction can disagree in real reports, so a parser should read the fraction and treat the percentage as derived.
The same coverage split into one package per source directory with dotted names, the layout a JVM project produces. Reports that key on class name alone collide as soon as two packages hold a class of the same name, which this file is shaped to expose.
A structurally complete Cobertura report in which line-rate and branch-rate are 0.0 everywhere. The counterpart to the zero-coverage LCOV file, for checking that a converter keeps the class and method structure when there is nothing covered to describe.
Three <source> roots with class filenames given relative to them, which is how Cobertura represents a multi-root project. A viewer must try each root in turn to resolve a file; one that assumes a single root shows "source not found" for most of the report.
All six JaCoCo counter types present at every level of the document — method, class, sourcefile, package and report. Tools usually read only the report-level LINE counter; this file is for checking that per-method and per-package rollups agree with it.
A report merged from three separate JVM sessions, each recorded as its own <sessioninfo> with start and dump timestamps. The counters are already the merged totals, so summing per-session anything from this file is a mistake it exists to catch.
The aggregate form a multi-module build produces: packages nested inside a <group> rather than directly under <report>. Parsers with a hardcoded report/package path find nothing here and report a module with no coverage at all.
Per-method INSTRUCTION, LINE, COMPLEXITY and METHOD counters for all 20 methods, 2 of which were never entered. This is the detail a "which functions are untested" report needs and the level at which most converters stop.
A tracefile sitting meets the gate exactly against the 80% minimum in this group's gate config: 112 of 140 lines, 80.00%. 80.00% is exactly the configured minimum, so a > comparison fails the build and a >= comparison passes it — the single most common off-by-one in a coverage gate.
A tracefile sitting misses the gate by one line against the 80% minimum in this group's gate config: 111 of 140 lines, 79.29%. 79.29% is one covered line short of the gate, the smallest possible failure.
A tracefile sitting clears the gate by one line against the 80% minimum in this group's gate config: 113 of 140 lines, 80.71%. 80.71% clears the gate by one covered line, the smallest possible pass.
The source feature for this whole group: a Background with a data table, a plain scenario, a Scenario Outline expanded by two Examples tables, and a scenario asserting against a doc string. It compiles to exactly six pickles and 32 pickle steps — the numbers the cucumber-messages and cucumber.json twins next to it report.
A named Background whose two steps are prepended to all three scenarios, plus feature-level tags that every scenario inherits and scenario-level tags that only some carry. Tag filtering is where this file earns its keep: @slow selects one scenario by its own tag and all three by inheritance from the feature.
One outline expanded by two separate Examples tables, the second of which carries its own @edge tag. Expansion must produce five scenarios, and only the two from the tagged table may match a run filtered on @edge — a distinction parsers that flatten the tables lose.
A step argument table with a header row, followed by two doc strings — one plain and one carrying a json content type after the opening delimiter. Doc string indentation is relative to the delimiter, so the receipt body must keep its internal column alignment while losing the six leading spaces.
Two Rule blocks, the first with its own Background that applies only to the examples inside it. Parsers written before Gherkin 6 either reject Rule outright or, worse, hoist the Background to the whole feature and add a step to the third example that was never there.
A feature written entirely in French keywords, declared by the # language: fr header that must be the first line of the file. Parsers that hardcode English keywords read this as a feature with no scenarios rather than reporting an error, so it fails silently.
Steps exercising every argument shape a step-definition matcher has to handle: quoted strings with escaped inner quotes, integers, decimals, a comma-and-and list, the But keyword, and angle brackets in a plain Scenario where they are literal text rather than outline placeholders.
A complete Robot Framework suite with all four common sections, scalar, list and dictionary variables, a continued line using ..., and user keywords with arguments. Robot separates arguments on two or more spaces, so a parser splitting on a single space merges every keyword call into one token.
The template form, in which the *** Test Cases *** header itself names the argument columns and each row becomes one test. Five tests share a single keyword body, and a parser that reads the header row as a test name reports six.
A resource file: keywords, variables and imports with no *** Test Cases *** section at all, meant to be imported by the suites next to it. Tooling that requires at least one test case rejects a perfectly ordinary resource, and keyword defaults such as ${qty}=1 are where argument parsers usually stop.
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.
The same change as the unified twin, emitted in the pre-unified context format: `*** before` and `--- after` blocks separated by a row of asterisks, with `!`, `+` and `-` change markers. Parsers that assume every diff starts with `---`/`+++` misread this one as a unified diff with no hunks.
The default output of bare `diff`: ed-style commands such as `3a4` with `<` and `>` bodies and no file headers at all. Tooling that identifies diffs by looking for `---`, `+++` or `@@` cannot even tell this is a diff, which is exactly what makes it a useful negative fixture.
The exact inverse of the single-hunk fixture: the same edit expressed as a deletion instead of an insertion. Applying both in sequence must return the file to its original bytes, which makes this the fixture for `patch -R` and for revert paths.
One TypeScript module edited in 2 places at once, so the hunks are far enough apart not to merge. Use it to check that a parser advances its line cursor by the hunk header rather than by counting emitted lines.
Three unrelated files changed in a single diff stream, with no `diff --git` lines to mark the boundaries — the only separator is the next `---` header. Splitters that key on `diff --git` see one file here instead of three.
A 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.
The 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.
`diff -U0` output: hunks contain nothing but +/- lines, and pure insertions produce ranges such as `-9,0`. Coverage and blame tools that need zero-context diffs hit this shape constantly, and hunk mergers that assume at least one context line get the offsets wrong.
The same edit as the zero-context fixture with ten lines of context, which merges the separate hunks into fewer, larger ones. Pair the two to check that a hunk-merging or context-trimming routine reaches the same applied result from either input.
A 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.
git 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.
Quilt, Debian and vendor trees check patches into the repository, so editing one produces a diff whose body is itself full of `+++`, `---` and `@@` lines and whose section heading is a `diff --git` line. Any scanner that finds file boundaries by searching for those tokens anywhere in the stream splits this single-file diff into several phantom files.
The before-state has no final newline and the after-state gains one, so the marker appears once, immediately after the last `-` line. The change is invisible in a rendered side-by-side view yet alters the file's bytes, which is why line-based comparators report a spurious no-op.
A 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.
Neither 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.
Indentation is converted from tabs to spaces and one line gains trailing whitespace, so the diff is large and the program is unchanged. It is the fixture for `-w`/`--ignore-all-space` handling and for review UIs that offer a hide-whitespace toggle.
A patch as it actually arrives in a mailing-list message: prose above it, a sign-off and an email signature below it, and a signature separator that looks like the start of a deletion. Extractors must find the diff without swallowing the surrounding text.
A complete format-patch message: the mbox `From <sha> Mon Sep 17 00:00:00 2001` line, RFC 5322 headers, a commit message with a Signed-off-by trailer, the `---` separator, a diffstat and the diff. The signature separator is `-- ` with the trailing space git actually writes, which editors love to strip.
A file creation carried by the `new file mode 100644` extended header rather than by the paths alone. The mode is the authoritative signal: the `--- /dev/null` line tells you the old side is empty, but only the header tells you what permissions to create the file with.
A deletion of an executable file, so the `deleted file mode 100755` header records the mode the file had rather than the mode to create. A patcher that writes an empty file here instead of unlinking leaves a broken executable behind.
A permission change and nothing else: the file section has `old mode`/`new mode` headers, no `index` line, no `---`/`+++` pair and no hunks at all. Parsers that require at least one hunk per file drop this change entirely and report an empty patch.
The same file changes permissions and content in one commit, so the mode headers are followed by an `index` line and a normal hunk. Applying only the hunk and silently ignoring the mode is the common failure, and it leaves a script that is no longer executable.
Git stores a symlink as a blob whose contents are the link target with no trailing newline, so this patch adds a single + line followed by the no-newline marker and marks it mode 120000. A patcher that ignores the mode writes a regular text file containing a path.
A rename with no content change at all: `similarity index 100%`, `rename from`, `rename to`, and then nothing — no index line and no hunks. This is the single most common patch shape that naive parsers lose, because there is no `@@` anywhere in the file section.
A rename that also edits the file, so the similarity index drops to 68% and the rename headers are followed by an index line and real hunks whose `---`/`+++` paths differ from each other. A patcher that applies hunks to the path on the `---` line writes to the file that no longer exists.
`copy from`/`copy to` headers, produced only when copy detection is enabled with `-C`. The source file still exists afterwards, which is the whole difference from a rename — and the difference a parser that maps both header pairs onto one 'moved' concept silently erases.
The `index` line abbreviates both blob ids to seven characters, which is what plain format-patch emits and what most patches in the wild carry. Three-way application can still fall back to path matching, but the blobs cannot be looked up unambiguously in a large repository.
The same patch with `--full-index`, so both blob ids are the complete 40 hex characters. This is what `git apply --3way` needs to find the pre-image blob, and comparing the two twins shows a parser must accept any hash length between 4 and 40.
The torture test: one commit that creates a file, deletes an executable, renames at 100%, copies with detection on, changes a mode while editing, and adds a binary blob. The diffstat carries the matching create/delete/rename/mode-change summary lines that follow the file table.
format-patch output for a commit created with `--allow-empty`: full mail headers, a commit message, the `---` separator, and then straight to the signature with no diffstat and no diff. Pipelines that treat 'no diff found' as a parse error reject a message that git itself considers valid.
The commit message uses `---` as a horizontal rule, so the file contains two lines that look like the diffstat separator. git's own mailinfo ends the message at the FIRST one, which quietly truncates the message and drops the rounding table — the patch still applies, but the recorded history is wrong.
A patch sent as a reply: the mail subject starts with `Re:`, quoted text sits above a `-- >8 --` scissors line, and the real commit subject and body sit below it. `git am --scissors` discards everything above the cut; a parser that trusts the mail Subject header records 'Re: [PATCH] ...' as the commit title.
The `--cover-letter` message git writes ahead of a series: a `[PATCH 0/3]` subject, a shortlog of the authors and their subjects, and the combined diffstat — but no diff of its own. Series tooling has to recognise it as metadata and not try to apply it.
Patch 1 of a three-message series, threaded under the cover letter with In-Reply-To and References headers. Applying the three out of order breaks: the series is only self-consistent in numeric order.
Patch 2 of a three-message series, threaded under the cover letter with In-Reply-To and References headers. Applying the three out of order breaks: the series is only self-consistent in numeric order.
Patch 3 of a three-message series, threaded under the cover letter with In-Reply-To and References headers. Applying the three out of order breaks: the series is only self-consistent in numeric order.
The same four messages concatenated into a single mbox, which is exactly what `git format-patch --stdout` produces and what `git am` consumes. The From_ separator lines use git's fixed sentinel date, so a splitter cannot rely on the timestamp being real.
An intentionally invalid patch: the file ends three lines into a hunk that declares many more, as it would after a truncated download or a mail client cutting the message. Nothing is corrupt at the byte level, so a parser must notice the count mismatch rather than applying a partial hunk.
An intentionally invalid patch whose hunk header claims 99 lines on each side while the body supplies far fewer. Every other byte is a well-formed patch, so this isolates one question: does the applier verify the declared counts, or does it trust them and read past the end of the hunk?
What `git show` prints for a merge commit: a `diff --cc` header, an index line naming three blobs, `@@@` hunk markers, and two prefix columns instead of one. The `++` line is the giveaway a reviewer is looking for — content that appears in the merge result but in neither parent.
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.
When the file mode differs between the parents and the merge result, a combined diff adds a `mode a,b..result` line below the index line — a comma-separated shape that appears nowhere else in git's output. Parsers written for the single-parent `old mode`/`new mode` pair do not recognise it.
A 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.
The 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.
The 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.
One 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.
A package manifest left mid-merge, so the file is intentionally invalid JSON: conflict markers sit inside the dependencies object. Any tool that reads manifests has to fail on this with a message about the conflict rather than a bare syntax error at line 5.
Documentation 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.
Someone 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.
What `git apply --reject` leaves behind when a hunk will not apply: the failed hunks alone, under a header that is neither `diff --git` nor a plain `---`/`+++` pair. Ships with its .orig twin so the pair can drive a resolve-the-reject workflow end to end.
The `.orig` backup GNU patch writes beside a file it has modified: the exact pre-patch content, kept so a failed application can be unwound. Paired with the .rej fixture, it is the complete state a developer actually finds after a patch goes wrong.
An intentionally invalid ownership file carrying five defects that all parse as plausible lines: an owner that is neither a handle nor an email, a team with no organisation, a character class, a negation, and a path with an unescaped space. Each is a separate assertion for a linter, and none of them is a syntax error a naive line splitter would notice.
Six commits as `git log --oneline` prints them: an abbreviated hash, a space, and the subject line. Every subject follows Conventional Commits, including one with a `!` breaking marker, so a release-notes generator can be scored against a known answer.
The default `git log` format for the same six commits: full 40-character hashes, Author and Date headers, and message bodies indented by exactly four spaces with genuinely empty separator lines. One commit carries a `BREAKING CHANGE:` footer and another a `Fixes:` footer, which is the shape a changelog generator has to find.
Per-commit file lists with single-letter status codes, tab-separated. Rename rows are the trap: `R100` is followed by TWO paths instead of one, so a splitter that takes field 2 as the filename reports the old path for renames and the new path for everything else.
Porcelain v1 output covering staged-only, worktree-only, added, renamed, deleted, unmerged, untracked and ignored entries. The two status characters are positional and a space is meaningful, so trimming the line before parsing turns ' M' (modified but unstaged) into 'M' (staged).
The v2 format for the same working tree: `# branch.*` headers first, then one record per entry whose leading character selects a completely different field layout. Rename records put the new path first and separate the two paths with a TAB rather than an arrow, and unmerged records carry three object ids instead of two.
An intentionally invalid commit message that breaks four commitlint rules at once: no conventional type, a 116-character header, no blank line separating subject from body, and a body that starts mid-sentence. Every rule should fire independently, which is what makes this useful for checking that a linter reports all violations rather than stopping at the first.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
