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 3 of 4; 24 results per page.
A realistic global config exercising the whole INI-like grammar: bracketed sections, quoted subsection names that are case-sensitive while section names are not, values with size suffixes, a shell alias whose leading `!` changes how the rest is executed, and both comment characters.
Every escape the format defines, including the one nobody expects: a trailing space is stripped from a pattern unless it is backslash-escaped, so `draft\ ` and `draft` ignore different files. Editors that trim trailing whitespace on save silently change what this file means.
One pattern per rule in the gitignore grammar: a leading slash that anchors to the containing directory, the same name unanchored, `**` in all three positions, `?` and `[...]` classes, and a trailing slash that matches only directories. Every line is a separate assertion for a matcher's test suite.
The single most misunderstood rule in the format: once `build/` excludes a directory, git does not descend into it, so `!build/keep.txt` is dead. The file is valid and the behaviour is documented — it is the author's expectation that is wrong, which is exactly why an ignore-matcher must reproduce it rather than being helpful.
A realistic monorepo ignore file that uses `dist/*` rather than `dist/` precisely so the two `!dist/...` re-inclusions below it can work. It also carries the `.env.*` / `!.env.example` and `*.log` / `!logs/retained/*.log` pairs that every ignore-matcher has to order correctly.
The corrected twin: `build/*` excludes the directory's contents instead of the directory, so git still descends and `!build/keep.txt` re-includes the file. The two fixtures differ by two characters and produce opposite results, which makes them a precise pass/fail pair for an ignore engine.
Three submodules covering the awkward values: a relative `../currency-tables.git` URL that has to be resolved against the superproject's remote, `branch = .` meaning 'the same branch as the superproject', and `ignore = dirty` which hides a submodule's local changes from `git status`. The section name and the `path` value are separate strings and are allowed to differ.
One line for each of the four rewrite forms git's mailmap supports, including the two-pair form that matches on the commit name as well as the email. Four aliases collapse onto three canonical authors, which is exactly the transformation a shortlog or contributor report has to reproduce.
The same conflict with `merge.conflictStyle=diff3`, which inserts the merge base between the two sides behind a row of pipes. Tools that split a conflict on `=======` alone silently fold the ancestor text into the ours side.
Someone committed a file that still contained conflict markers, and merging that commit produced markers inside markers. Region matchers that pair the first `<<<<<<<` with the first `=======` split this file in the wrong place and produce two overlapping regions that cannot both be resolved.
Documentation about merge conflicts that quotes the markers inside a fenced code block, and then genuinely conflicts further down. A pre-commit hook that greps for `^<<<<<<<` reports two hits and blocks a clean commit; one that understands Markdown fences reports the one that matters.
One file left with three independent unresolved regions and clean text between them, which is what a real deployment-values merge looks like. Editors that jump to 'the next conflict' and resolvers that report a boolean rather than a count both get exercised here.
A working-tree file left mid-merge in git's default `merge` conflict style: our version, a row of equals signs, their version, and branch labels on the opening and closing markers. Both sides happen to end with the same line, which the zdiff3 twin in this group hoists out and this style repeats.
The identical merge under `merge.conflictStyle=zdiff3`, which hoists lines common to both sides out of the conflict region — here 'jitter: on' moves below the closing marker. Diff this against the diff3 twin to see that the same conflict produces different file contents depending on one config value.
The message template git writes into .git/MERGE_MSG when a merge stops on conflicts: one real subject line followed by a commented list of the conflicted paths and the standard advice block. Everything after the first blank line is stripped by `git commit`, so a hook that lints the whole file rejects messages git would accept.
The default output of bare `diff`: ed-style commands such as `3a4` with `<` and `>` bodies and no file headers at all. Tooling that identifies diffs by looking for `---`, `+++` or `@@` cannot even tell this is a diff, which is exactly what makes it a useful negative fixture.
The `.orig` backup GNU patch writes beside a file it has modified: the exact pre-patch content, kept so a failed application can be unwound. Paired with the .rej fixture, it is the complete state a developer actually finds after a patch goes wrong.
A package manifest left mid-merge, so the file is intentionally invalid JSON: conflict markers sit inside the dependencies object. Any tool that reads manifests has to fail on this with a message about the conflict rather than a bare syntax error at line 5.
What `git apply --reject` leaves behind when a hunk will not apply: the failed hunks alone, under a header that is neither `diff --git` nor a plain `---`/`+++` pair. Ships with its .orig twin so the pair can drive a resolve-the-reject workflow end to end.
A one-line file changed in place. Both ranges have length one, so the header is written `@@ -1 +1 @@` with no comma and no count — the abbreviation the unified format allows and that regexes of the form `-(\d+),(\d+)` fail to match.
Byte-for-byte the same diff as its LF twin except that every line ends CR LF, which is what a diff produced or saved on Windows looks like. Readers that compare a hunk line against expected content without stripping the CR find that no line matches.
The mirror of the added-file fixture: every line is a deletion and the new range is `+0,0`. A renderer that writes an empty file instead of unlinking it, or that reports the change as a truncation, fails this one.
Quilt, Debian and vendor trees check patches into the repository, so editing one produces a diff whose body is itself full of `+++`, `---` and `@@` lines and whose section heading is a `diff --git` line. Any scanner that finds file boundaries by searching for those tokens anywhere in the stream splits this single-file diff into several phantom files.
git appends the enclosing declaration after the closing `@@` of each hunk header. The text is free-form and is not part of the range, so a parser that splits the header on `@@` and takes the last field reads the function signature as a range.
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.
