Git Patch - Intentionally Invalid Hunk Line Counts
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?
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,99 +1,99 @@
package ledger
-import "errors"
+import (
+ "errors"
+ "fmt"
+)
// ErrShortBalance is returned when a posting would drive the balance negative.
var ErrShortBalance = errors.New("ledger: insufficient balance")
// Apply posts one delta against the running balance and returns the new total.
+// A zero delta is a no-op and never reports an error.
func Apply(balance, delta int64) (int64, error) {
+ if delta == 0 {
+ return balance, nil
+ }
if balance+delta < 0 {
- return balance, ErrShortBalance
+ return balance, fmt.Errorf("%w: balance %d, requested %d", ErrShortBalance, balance, delta)
}
return balance + delta, nil
}
--
2.43.0
Specifications
- Seed
- 20260807
- Intentionally Invalid
- true
- Defect
- hunk header declares 99/99 lines
- Declared Old Lines
- 99
- Declared New Lines
- 99
- Line Endings
- LF
- Encoding
- UTF-8
Testing contract
Expected to fail- Scenario
- Apply a patch whose hunk header line counts do not match the number of lines that follow.
- Expected result
- The applier rejects the hunk with a count-mismatch error instead of consuming the following file section as hunk content.
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 Hunk Line Counts” 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.