Git Patch - Empty Commit With No Diff
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.
From efcd4c3e50631c3788989a1e24ae01f20b84a149 Mon Sep 17 00:00:00 2001
From: Miguel Otero <miguel.otero@example.invalid>
Date: Tue, 10 Mar 2026 09:00:00 +0000
Subject: [PATCH] chore: retag 4.3.0 after the CI outage
Created with git commit --allow-empty so the tag has something to point at.
---
--
2.43.0
Specifications
- Seed
- 20260807
- Files
- 0
- Hunks
- 0
- Has Diff
- false
- Allow Empty
- true
- Line Endings
- LF
- Encoding
- UTF-8
Testing contract
Expected to pass- Scenario
- Feed a format-patch message that contains no diff at all to a patch pipeline.
- Expected result
- The message parses successfully with zero file sections and a non-empty commit subject; it is not reported as malformed.
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 - Empty Commit With No Diff” is a deterministic Testaroo 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.
Generated by generation/version_control.py. Free for any use, no attribution required, license.
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 - 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.
