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 1 of 4; 24 results per page.
The machine-generated twin of the hand-written changelog: version headings that are themselves compare links, a leading warning glyph on the breaking-changes section, and every entry ending in a short-hash link back to the commit. The hashes are the same fictional ids used by the log fixtures in this category.
A hand-maintained changelog in the Keep a Changelog layout: an Unreleased section, dated version headings in square brackets, the standard change-type subheadings, and reference-style compare links at the bottom. It describes the same releases as the generated twin in this group, so a converter between the two can be scored.
An 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.
Deliberately overlapping rules so every interesting path matches two or three of them, which is the only way to test that a resolver applies last-match-wins rather than most-specific-wins. One rule has no owners at all, which clears inherited ownership instead of adding any.
What `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.
An 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.
When the file mode differs between the parents and the merge result, a combined diff adds a `mode a,b..result` line below the index line — a comma-separated shape that appears nowhere else in git's output. Parsers written for the single-parent `old mode`/`new mode` pair do not recognise it.
A breaking change announced twice, which the specification allows: a `!` after the scope and a `BREAKING CHANGE:` footer whose value continues onto a second line. Generators that stop a footer at the first newline lose half the sentence, and version bumpers that only look for one of the two markers under-bump the release.
An intentionally invalid commit message that breaks four commitlint rules at once: no conventional type, a 116-character header, no blank line separating subject from body, and a body that starts mid-sentence. Every rule should fire independently, which is what makes this useful for checking that a linter reports all violations rather than stopping at the first.
A commit message file exactly as `git commit` hands it to a commit-msg hook: a conventional subject, a wrapped body, two trailers, and git's own comment block that the hook must ignore. The subject is 43 characters, comfortably inside commitlint's default 72-character header limit.
The same change as the unified twin, emitted in the pre-unified context format: `*** before` and `--- after` blocks separated by a row of asterisks, with `!`, `+` and `-` change markers. Parsers that assume every diff starts with `---`/`+++` misread this one as a unified diff with no hunks.
The stable machine format of git blame: a full header block the first time a commit appears and a bare `<sha> <old> <new>` line every time after, with each source line following on a tab-prefixed line. A parser that expects the header on every group loses the author of every line after the first.
The `--cover-letter` message git writes ahead of a series: a `[PATCH 0/3]` subject, a shortlog of the authors and their subjects, and the combined diffstat — but no diff of its own. Series tooling has to recognise it as metadata and not try to apply it.
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.
Patch 2 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.
Patch 3 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.
The same four messages concatenated into a single mbox, which is exactly what `git format-patch --stdout` produces and what `git am` consumes. The From_ separator lines use git's fixed sentinel date, so a splitter cannot rely on the timestamp being real.
Per-commit file lists with single-letter status codes, tab-separated. Rename rows are the trap: `R100` is followed by TWO paths instead of one, so a splitter that takes field 2 as the filename reports the old path for renames and the new path for everything else.
Machine-readable insertion and deletion counts per file. Two rows break naive arithmetic: the binary file reports `-` in both numeric columns rather than 0, and the rename path is brace-compressed into `docs/{README.md => guide.md}` rather than written out twice.
Six commits as `git log --oneline` prints them: an abbreviated hash, a space, and the subject line. Every subject follows Conventional Commits, including one with a `!` breaking marker, so a release-notes generator can be scored against a known answer.
The default `git log` format for the same six commits: full 40-character hashes, Author and Date headers, and message bodies indented by exactly four spaces with genuinely empty separator lines. One commit carries a `BREAKING CHANGE:` footer and another a `Fixes:` footer, which is the shape a changelog generator has to find.
The `index` line abbreviates both blob ids to seven characters, which is what plain format-patch emits and what most patches in the wild carry. Three-way application can still fall back to path matching, but the blobs cannot be looked up unambiguously in a large repository.
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.
`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.
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.
