What is a .patch file?
text/x-patch
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 a .patch 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.
Download example .patch files
- Git Patch - Single File With Full Mail HeadersA complete format-patch message: the mbox `From <sha> Mon Sep 17 00:00:00 2001` line, RFC 5322 headers, a commit message with a Signed-off-by trailer, the `---` separator, a diffstat and the diff. The signature separator is `-- ` with the trailing space git actually writes, which editors love to strip.
- Git 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.
- Git 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.
- Git 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.
- Git 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.
- Git Patch - Symlink Created With mode 120000Git stores a symlink as a blob whose contents are the link target with no trailing newline, so this patch adds a single + line followed by the no-newline marker and marks it mode 120000. A patcher that ignores the mode writes a regular text file containing a path.
- Git Patch - Pure Rename at similarity index 100%A rename with no content change at all: `similarity index 100%`, `rename from`, `rename to`, and then nothing — no index line and no hunks. This is the single most common patch shape that naive parsers lose, because there is no `@@` anywhere in the file section.
- Git Patch - Rename Plus Edits at similarity index 68%A rename that also edits the file, so the similarity index drops to 68% and the rename headers are followed by an index line and real hunks whose `---`/`+++` paths differ from each other. A patcher that applies hunks to the path on the `---` line writes to the file that no longer exists.
and 17 more in the library.