Git Format-Patch Series - 0001 of 3
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.
From cdbd7c648caa53322292d5709d478c2c3caaa38e Mon Sep 17 00:00:00 2001
From: Ada Fernsby <ada.fernsby@example.invalid>
Date: Mon, 2 Mar 2026 09:14:03 +0000
Subject: [PATCH 1/3] feat(ledger): treat a zero delta as a no-op
In-Reply-To: <024f75262757878b20f7a3e64c1472d87a75d6b8.1772442000.git.ada.fernsby@example.invalid>
References: <024f75262757878b20f7a3e64c1472d87a75d6b8.1772442000.git.ada.fernsby@example.invalid>
Apply returned a wrapped error for zero-value postings, which the
reconciliation job counted as a failure.
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
- Series Position
- 1/3
- Files
- 1
- Threaded
- true
- In Reply To
- cover letter
- Line Endings
- LF
- Encoding
- UTF-8
Testing contract
Expected to pass- Scenario
- Apply message 1 of a threaded series in sequence with its siblings.
- Expected result
- The subject prefix parses as 1 of 3 and the message threads under the cover letter's Message-ID.
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 Format-Patch Series - 0001 of 3” is a deterministic Testaroo fixture for Visual diff / regression, Code parsing, Editor testing. A/B image twins with controlled pixel changes, anti-alias variants, and UI chrome crops for screenshot diff and visual regression tools.
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.
Treat A/B twins as a visual regression unit: run your pixel or perceptual diff, assert a non-zero delta on the changed twin, and keep thresholds calibrated against the documented change kind in specs.
Generated by generation/version_control.py. Free for any use, no attribution required, license.
Related files
- patchGit Patch - Copy Detection at similarity index 85%`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.

- patchGit Patch - deleted file mode HeaderA 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.

- patchGit Patch - Every Extended Header in One CommitThe 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.

- patchGit Patch - Mode Change Plus Content EditThe 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.

- patchGit Patch - Mode Change With No HunksA 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.

- patchGit Patch - new file mode HeaderA 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.
