Git Log - --name-status With Rename Scores
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.
b06c629 feat(rounding)!: round half to even instead of half up
M internal/ledger/rounding.go
232f149 fix(format): reject amounts with no digits
M web/src/format.ts
e178e16 chore: the quarterly tidy-up
A internal/ledger/rounding.go
D scripts/legacy-import.sh
R100 docs/README.md docs/guide.md
M scripts/release.sh
A assets/badge.png
337d122 docs: rename README to guide
R100 docs/README.md docs/guide.md
4cea2b8 feat(ledger): add banker's rounding helper
A internal/ledger/rounding.go
437e21e feat(ledger): treat a zero delta as a no-op
M internal/ledger/apply.go
Specifications
- Seed
- 20260807
- Command
- git log --oneline --name-status -6
- Commits
- 6
- Status Codes
- A, D, M, R100
- Rename Rows Have Two Paths
- true
- Field Separator
- TAB
- Line Endings
- LF
- Encoding
- UTF-8
Testing contract
Expected to pass- Scenario
- Build a per-commit changed-file list from --name-status output that contains rename rows.
- Expected result
- Rename rows yield both paths (docs/README.md and docs/guide.md) with a similarity score of 100, and non-rename rows yield exactly one path each.
What is a .log file?
LOG files are plain-text records of events emitted by software, typically one entry per line with a timestamp, severity, and message. There is no single standard, so formats range from unstructured text to structured JSON lines. They are central to debugging, monitoring, and auditing.
How to use this file
Use an example LOG file to test log parsers, timestamp and severity extraction, line-oriented streaming, and ingestion into monitoring or analysis pipelines.
How to use this file for testing
“Git Log - --name-status With Rename Scores” is a deterministic Novus Examples fixture for Log parsing, Visual diff / regression, Code parsing. Access logs and JSON-lines application logs — for testing log parsers, tailers, and ingestion pipelines.
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.
Code examples
grep -i error git-log-name-status.log | head
awk '{print $1, $2, $NF}' git-log-name-status.log | headRelated files
- logGit Log - --oneline OutputSix 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.
- logGit Log - Default Format With Conventional Commit BodiesThe 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.
- logGit Status - Porcelain v1 With Every Status PairPorcelain 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).
- logGit Status - Porcelain v2 With Branch HeadersThe 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.
- txtCommit Message - Intentionally Invalid, Four Rule ViolationsAn 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.
- logGit Blame - Porcelain Format With Repeated Commit HeadersThe 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.
Generated by generation/version_control.py. Free for any use, no attribution required — license.