Git Patch - Intentionally Invalid, Truncated Mid-Hunk
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.
From 2a88a4a951f7a0358e5e55aec3f38195d80c866a Mon Sep 17 00:00:00 2001
From: Ada Fernsby <ada.fernsby@example.invalid>
Date: Fri, 13 Mar 2026 09:00:00 +0000
Subject: [PATCH] fix(ledger): guard the zero delta
Base message for the intentionally invalid fixtures.
---
internal/ledger/apply.go | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/internal/ledger/apply.go b/internal/ledger/apply.go
index 95f499d..ce501c6 100644
--- a/internal/ledger/apply.go
+++ b/internal/ledger/apply.go
@@ -1,14 +1,21 @@
package ledger
-import "errors"
Specifications
- Seed
- 20260807
- Intentionally Invalid
- true
- Defect
- file ends mid-hunk
- Declared Hunk Lines
- 14
- Supplied Hunk Lines
- 3
- Line Endings
- LF
- Encoding
- UTF-8
Testing contract
Expected to fail- Scenario
- Apply a patch whose final hunk stops before it has supplied the number of lines its header declares.
- Expected result
- The applier fails with an explicit 'unexpected end of file' or 'corrupt patch' style error and leaves the working tree untouched — it must not apply the partial hunk.
What is a .patch file?
A .patch file is a unified diff packaged for transmission, most often as produced by `git format-patch`. Beyond the diff itself it carries an email-style header with the author, date, and commit subject, a commit message body, per-file `diff --git` headers recording renames and mode changes, and hunk headers of the form `@@ -old,count +new,count @@`. Applying it reconstructs a specific change against a specific before-state.
How to use this file
Use an example .patch file to test patch application, code-review renderers, and diff parsers — exercising renames, mode changes, binary hunks, added and deleted files, and the `\ No newline at end of file` marker that naive parsers silently drop.
How to use this file for testing
“Git Patch - Intentionally Invalid, Truncated Mid-Hunk” 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
- patchGit Patch - Bare --- Line Inside the Commit MessageThe 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.
- patchGit Patch - Empty Commit With No Diffformat-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.
- diffCombined Diff - diff --cc With Two ParentsWhat `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.
- diffCombined Diff - Octopus Merge With Three ParentsAn 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.
- diffCombined Diff - Per-Parent mode LineWhen 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.
- txtCommit Message - Intentionally Invalid, Four Rule ViolationsAn 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.
Generated by generation/version_control.py. Free for any use, no attribution required — license.