Git Patch - Bare --- Line Inside the Commit Message
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.
From f25719592367f141da2df8d19fd447dc82bf5cb4 Mon Sep 17 00:00:00 2001
From: Ada Fernsby <ada.fernsby@example.invalid>
Date: Wed, 11 Mar 2026 10:05:33 +0000
Subject: [PATCH] docs(rounding): record the rounding table
Rounding now follows the table below.
---
step | mode
-----+-----------
5 | half-even
25 | half-even
Signed-off-by: Ada Fernsby <ada.fernsby@example.invalid>
---
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"
+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
- Separator Ambiguity
- true
- Dash Lines
- 2
- Files
- 1
- First Separator Is Real
- false
- Line Endings
- LF
- Encoding
- UTF-8
Testing contract
Expected to recover- Scenario
- Split a format-patch message into commit message and diff when the message body itself contains a bare --- line.
- Expected result
- The diff is still found and applies cleanly, and the tool reproduces git's documented behaviour of ending the message at the first --- (losing the table) rather than inventing a third interpretation.
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 - Bare --- Line Inside the Commit Message” 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 - 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.

- patchGit Patch - Intentionally Invalid Hunk Line CountsAn 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?

- patchGit Patch - Intentionally Invalid, Truncated Mid-HunkAn 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.

- txtCODEOWNERS - Intentionally Invalid, Five Distinct DefectsAn 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.

- 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.

Generated by generation/version_control.py. Free for any use, no attribution required — license.