Search files, editable visual templates, and live browser targets from one registry-backed directory. Filtered query views stay crawlable for links but are deliberately noindex; the stable taxonomy pages below remain the canonical search surfaces.
Page 2 of 4; 24 results per page.
The whole patch file uses CRLF terminators, as it would after a round trip through a Windows editor or a mail client. `git am` needs `--keep-cr` to be told the CRs belong to the patch rather than to the content, and the `-- ` signature line now ends with space-CR-LF.
A 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.
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.
The 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.
The same patch with `--full-index`, so both blob ids are the complete 40 hex characters. This is what `git apply --3way` needs to find the pre-image blob, and comparing the two twins shows a parser must accept any hash length between 4 and 40.
A real binary file carried inside a text patch: zlib-deflated, encoded in git's own base85 alphabet, split into length-prefixed lines, and followed by the reverse `literal 0` payload that makes the patch revertible. The index line uses full 40-character hashes because `--binary` implies `--full-index`, and the recorded blob sha1 is the genuine object id of the attached PNG.
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?
An 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.
The LF half of the patch twin pair, identical in text content to the CRLF fixture. Diff the two downloads to get a change that is invisible in every renderer and fatal to a byte comparison.
The 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.
A 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.
A 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.
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.
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.
Non-ASCII in the author name and the subject, so both are Q-encoded into `=?UTF-8?q?...?=` words and the subject is folded across two lines with a leading space. The body is left as raw UTF-8, which means one message needs two different decoders.
A patch sent as a reply: the mail subject starts with `Re:`, quoted text sits above a `-- >8 --` scissors line, and the real commit subject and body sit below it. `git am --scissors` discards everything above the cut; a parser that trusts the mail Subject header records 'Re: [PATCH] ...' as the commit title.
A 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 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.
The author-grouped summary git generates for release notes: a name, a commit count in parentheses, and the subjects indented by six spaces. The counts here are what the .mailmap fixture in this category produces after coalescing aliases, so the two files can be used together.
Porcelain v1 output covering staged-only, worktree-only, added, renamed, deleted, unmerged, untracked and ignored entries. The two status characters are positional and a space is meaningful, so trimming the line before parsing turns ' M' (modified but unstaged) into 'M' (staged).
The v2 format for the same working tree: `# branch.*` headers first, then one record per entry whose leading character selects a completely different field layout. Rename records put the new path first and separate the two paths with a TAB rather than an arrow, and unmerged records carry three object ids instead of two.
The attribute file that decides what happens to line endings on checkout: `text=auto` as the default, explicit `eol=lf` and `eol=crlf` overrides, the `binary` macro that expands to `-text -diff`, and one `-text` entry that is still given a textconv driver. This is the file whose absence causes the CRLF twins elsewhere in this category.
The non-EOL half of the format: LFS filter/diff/merge triples, `linguist-generated` and `linguist-vendored` hints that hide files from language statistics and review, `export-ignore` entries that drop paths from `git archive`, and a `merge=union` driver for an append-only changelog. Attribute values are unquoted and space-separated, so column alignment is whitespace a parser must collapse.
Every conditional-include form git supports — path prefix, case-insensitive path prefix, branch glob, and a condition on an existing remote URL — plus one unconditional include. Order matters: a later include overrides an earlier one, so a parser that gathers includes into a set rather than a list resolves the wrong identity.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
