If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/dandavison/delta shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 6w ago
• 20 active contributors
• Distributed ownership (top contributor 42% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live dandavison/delta repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dandavison/delta.

What it runs against: a local clone of dandavison/delta — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in dandavison/delta | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 70 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of dandavison/delta. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/dandavison/delta.git
#   cd delta
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of dandavison/delta and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "dandavison/delta(\\.git)?\\b" \\
  && ok "origin remote is dandavison/delta" \\
  || miss "origin remote is not dandavison/delta (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "src/main.rs" \\
  && ok "src/main.rs" \\
  || miss "missing critical file: src/main.rs"
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "ARCHITECTURE.md" \\
  && ok "ARCHITECTURE.md" \\
  || miss "missing critical file: ARCHITECTURE.md"
test -f "manual/src/how-delta-works.md" \\
  && ok "manual/src/how-delta-works.md" \\
  || miss "missing critical file: manual/src/how-delta-works.md"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 70 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~40d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/dandavison/delta"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Delta is a syntax-highlighting pager written in Rust that replaces the default output formatter for git diff, git log -p, git blame, and grep tools (rg, git grep). It renders diffs with language-aware syntax highlighting (via syntect), word-level edit inference using Levenshtein distance, side-by-side viewing, and line numbers—making large changesets human-readable at a glance. Monolithic Rust binary (src/main.rs entry point) with modular organization: parsing layer handles various input formats (git diff, grep JSON, blame), a syntax highlighting layer wraps syntect/bat, and a rendering layer outputs styled text to stdout. Configuration flows through clap CLI parsing into runtime state. The etc/ directory contains examples, shell completions, and CI helpers separate from core logic.

Software developers who use Git daily and want better visual diff comprehension, particularly those reviewing large changesets in terminals. Git maintainers and DevOps engineers configuring Git workflows benefit from merge conflict display improvements and blame hyperlink support for GitHub/GitLab/SourceHut.

Production-ready and actively maintained. The codebase is well-established (v0.19.2), has comprehensive CI/CD via .github/workflows/ci.yml, uses snapshot testing with insta, and shows consistent commit activity. The presence of completion scripts (etc/completion/), Docker support, and detailed documentation indicates a mature, widely-adopted tool.

Low risk for core usage, moderate risk for extended customization. Single maintainer (Dan Davison) visible in Cargo.toml; dependency count is moderate (~25 direct deps) but includes syntect (complex regex engine), bat (large codebase), and git2 (system FFI). No breaking-change indicators visible, though the --color-only flag and interactive mode add complexity that could introduce regressions.

No recent commit data provided, but the file structure shows active workflow maintenance (.github/workflows/audit.yml, cd.yml, ci.yml), ongoing example test cases in etc/examples/ (including merge conflict and within-line edit cases), and a Makefile suggesting local development tooling. The presence of ARCHITECTURE.md and CONTRIBUTING.md indicates ongoing documentation effort.

git clone https://github.com/dandavison/delta.git
cd delta
cargo build --release
./target/release/delta --help

Or install via package manager: brew install git-delta (macOS), apt install git-delta (Ubuntu), etc. Then add to ~/.gitconfig as shown in README.

Daily commands:

# Development build
cargo build

# Run directly
cargo run -- --help

# Use as git pager
git config --global core.pager 'delta'
git diff  # will now use delta

# Run tests
cargo test

# Check with Makefile (if available)
make  # see Makefile for targets

• src/main.rs — Entry point for the delta binary; orchestrates CLI argument parsing and core paging/highlighting pipeline.
• Cargo.toml — Project manifest defining all dependencies (bat for syntax highlighting, ansi_term for color, regex engines); critical for build reproducibility.
• ARCHITECTURE.md — High-level design document explaining how delta parses diffs, applies syntax highlighting, and handles different input formats (git, grep, rg).
• manual/src/how-delta-works.md — Technical walkthrough of the core algorithm for diff parsing, line classification, and rendering; essential context for most code changes.
• .github/workflows/ci.yml — Continuous integration pipeline defining test matrix, coverage reporting, and release build steps across platforms.
• etc/examples — Curated test fixtures (119 through 822 series) for regression testing against real-world diffs; essential reference for understanding edge cases.

• Config Parser (src/config.rs) (Rust clap library (likely), gitconfig format parsing) — Merges CLI arguments and gitconfig settings; produces a Config struct used by all downstream components.
  • Failure mode: Misc

Add a new output format or input parser

1. Define a new variant in the InputType enum (e.g., GrepJson, RgJson) in src/config.rs (src/config.rs)
2. Implement parsing logic in src/diff_parser.rs to handle the new format's line prefixes and hunk structure (src/diff_parser.rs)
3. Add test fixtures in etc/examples/ named with a new issue/feature number (e.g., 999-my-new-format.diff) (etc/examples)
4. Document the new format in manual/src/ (e.g., create manual/src/grep-json.md and update SUMMARY.md) (manual/src/SUMMARY.md)

Add a new color theme or style

1. Define theme colors and styles in src/color.rs or in a new module if the theme is complex (src/color.rs)
2. Register the theme in src/syntax_theme.rs so it can be selected via --syntax-theme or gitconfig (src/syntax_theme.rs)
3. Add documentation in manual/src/custom-themes.md or manual/src/choosing-colors-styles.md with examples (manual/src/choosing-colors-styles.md)
4. Test with example diffs in etc/examples/ to ensure the theme renders correctly for all line types (etc/examples)

Add a new interactive navigation feature or keybinding

1. Define the keybinding handler in src/pager.rs within the event loop (src/pager.rs)
2. Implement the corresponding logic in the Pager struct (e.g., jump to next hunk, search within diff) (src/pager.rs)
3. Add the keybinding to the help text and document it in manual/src/navigation-keybindings-for-large-diffs.md (manual/src/navigation-keybindings-for-large-diffs.md)

Add a new configuration option

1. Add a new field to the Config struct in src/config.rs and define its CLI/gitconfig key (src/config.rs)
2. Integrate the option into the parsing logic (either in config.rs or a dedicated parser module) (src/config.rs)
3. Pass the option through to the relevant painting/paging logic (e.g., src/paint.rs or src/pager.rs) (src/paint.rs)
4. Document the option in manual/src/configuration.md with examples and rationale (manual/src/configuration.md)

• Rust (Edition 2018) — Provides memory safety and performance critical for a high-throughput pager that processes large diffs without copying input unnecessarily.
• bat (syntax highlighter library) — Reuses battle-tested syntax highlighting logic and Sublime-compatible theme system rather than reimplementing from scratch.
• ansi_term / anstyle-parse — Handles ANSI color parsing and generation; abstracts away terminal color model complexity (256-color, true-color, Windows).
• regex-onig (Oniguruma regex) — Supports complex regex patterns in syntax definitions; required by bat's syntax highlighting system.
• chrono — Timestamp handling for git blame output integration.

• Streaming line-by-line parsing rather than loading entire diff into memory

  • Why: Enables delta to handle arbitrarily large diffs without memory bloat; critical for large repository operations.
  • Consequence: Cannot perform multi-pass analysis; must decide line styling in a single forward pass, limiting some cross-line optimizations.

• Tight integration with bat for syntax highlighting

  • Why: Avoids duplicate syntax definition maintenance and reuses a mature ecosystem.
  • Consequence: Delta inherits bat's dependency chain (oniguruma regex) and must track bat API changes; cannot use alternative syntax engines without major refactor.

• Interactive paging via terminal control (not external pager like less)

  • Why: Allows delta to inject its own keybindings (navigate hunks) and apply color to the pager itself.
  • Consequence: Requires careful terminal state management and cross-platform testing (Windows console, Unix terminals); cannot fall back to standard pager behavior for edge cases.

• Unified diff format as primary internal representation

  • Why: Universal standard supported by git, rg, grep; minimizes parser complexity.
  • Consequence: Cannot represent non-unified formats (e.g., side-by-side diffs) without conversion; some metadata (e.g., rename similarity) is lossy.

• Does not generate diffs; only renders and enhances existing diff output.
• Does not serve as a git replacement or reimplement core git functionality.
• Does not support real-time diff streaming from live source code edits (processes completed diffs only).
• Does not provide a GUI; terminal-only tool.
• Does not attempt to merge or apply diffs; display-only.

No required env vars, but XDG_CONFIG_HOME and XDG_CACHE_HOME affect config/theme loading (dirs crate, xdg crate). Syntect regex complexity: The oniguruma regex engine (via syntect and bat with regex-onig feature) can be slow on deeply nested code; no obvious performance guardrails in place. Unicode width handling: unicode-width is pinned to >=0.1.14, <0.2.0 due to \n handling quirks (see Cargo.toml comment); upgrading breaks line length calculations. Git config interactions: delta modifies terminal behavior; ensure core.pager isn't double-wrapped or delta won't receive TTY properly. ANSI escape state machine: Processing streaming ANSI from git/grep is stateful; incomplete sequences at buffer boundaries could cause color bleed (check anstyle-parse usage).

• Levenshtein Edit Inference — Delta's core word-level diff highlighting uses Levenshtein distance to infer character-level edits within changed lines; understanding this algorithm is key to contributing to diff rendering logic
• ANSI Escape Sequences & Color Codes — Delta's output is ANSI-colored text; contributors working on styling, theme support, or color detection must understand ANSI SGR (Select Graphic Rendition) codes and state machine parsing
• Streaming Line-by-Line Processing — Delta processes stdin via bytelines without loading entire diffs into memory; understanding lazy evaluation and buffering is critical for performance and correctness in parsing large files
• Syntax Highlighting via Regex-Based Tokenization — Delta uses syntect (which uses oniguruma regex engine) for language-aware syntax highlighting; contributing to language support or theming requires understanding how TextMate grammars work
• Unified Diff Format & Hunk Structure — Delta's parser must recognize diff hunks (@@...@@), file headers, and context lines; understanding the unified diff spec is essential for adding input format support or fixing parsing bugs
• Unicode Width vs. Byte Length — Delta uses unicode-width crate (pinned version due to historical bugs) to calculate display width of characters; this matters for line wrapping and side-by-side alignment with emoji/CJK characters
• Terminal Paging & TTY Detection — Delta integrates as a core.pager in Git, requiring correct TTY handling and interactive mode support; understanding how pagers receive piped input and control terminal behavior is crucial

• sharkdp/bat — delta depends on bat for syntax highlighting themes and paging logic; understanding bat's theme system is essential for theming contributions to delta
• sharkdp/fd — Companion tool from same ecosystem author; similar UX design philosophy (simple, fast CLI with sensible defaults)
• BurntSushi/ripgrep — delta supports rg --json output formatting; ripgrep is a primary user of delta in grep workflows
• so-fancy/diff-so-fancy — delta explicitly provides emulation mode for diff-so-fancy output; understanding diff-so-fancy's approach helps refine delta's compatibility
• dandavison/dot — Maintainer's other project; delta philosophy (simple, opinionated defaults for dev tools) is consistent across their work

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for merge conflict rendering

The repo contains 5 merge conflict example files (etc/examples/189-merge-conflict-.diff and 125-merge-conflict-.diff, plus 822-hunk-header-within-merge-conflict.diff) but lacks corresponding test cases in the test suite. These are complex edge cases that deserve regression tests. This would improve confidence in the conflict handling code and prevent regressions.

• [ ] Create tests/merge_conflict_tests.rs with test cases for each etc/examples file containing merge conflicts
• [ ] Parse each conflict example and assert correct hunk header detection and syntax highlighting
• [ ] Add edge case tests for conflict markers within hunk headers (822 case)
• [ ] Integrate tests into CI via ci.yml workflow

Add integration tests for submodule diff handling

The repo has 2 submodule examples (etc/examples/60-submodule and 662-submodules) that demonstrate specific git diff output, but there are no corresponding test cases. Since submodule diffs have unique formatting, adding tests would prevent regressions and ensure the feature remains robust.

• [ ] Create tests/submodule_diff_tests.rs to parse and validate the example diff outputs
• [ ] Test both simple submodule cases and multiple submodule scenarios
• [ ] Assert correct line classification (context, addition, deletion) for submodule entries
• [ ] Add assertions for proper hunk header detection in submodule diffs

Implement automated snapshot tests for all etc/examples/ diff files

The repo already uses insta (snapshot testing framework) in dev-dependencies but there's no systematic coverage of the 40+ example files in etc/examples/. These examples serve as the ground truth for delta's output, so snapshot tests would catch unintended rendering changes and serve as living documentation.

• [ ] Create tests/examples_snapshot_tests.rs that iterates over all etc/examples/*.diff files
• [ ] For each file, parse with delta's diff parser and generate ANSI-colored output snapshots using insta
• [ ] Use insta's filters to normalize timestamps/paths for stable snapshots (see CONTRIBUTING.md for guidelines)
• [ ] Run cargo insta review during development and commit .insta snapshots to enable regression detection

• Add regression tests for etc/examples/ directory: write a test harness that compares delta output snapshots against golden files for each example in etc/examples/ to catch future regressions automatically: Examples exist but aren't formally tested; this catches visual regressions early
• Expand ARCHITECTURE.md with a module-by-module walkthrough and a data flow diagram (text-based) showing how input flows from stdin parsing → hunk detection → syntax highlighting → ANSI output: New contributors struggle to understand the control flow; concrete diagrams reduce onboarding time
• Add --perf-profile or --debug-timing flag to measure time spent in each stage (parsing, syntax highlighting, rendering) for performance bottleneck identification: No built-in profiling; users and maintainers can't easily identify which step is slow on large diffs

The delta project has a reasonable security posture as a command-line utility. Primary concerns are outdated dependencies (especially git2 v0.20.0) that may contain unpatched vulnerabilities, and the need to audit regex/shell command processing for untrusted input handling. The project uses Rust, which provides memory safety guarantees. Regular dependency updates via cargo audit and dependabot are recommended. No hardcoded secrets, SQL injection, or XSS risks were identified in the visible file structure.

• Medium · Dependency on git2 with disabled features — Cargo.toml - git2 dependency. The git2 dependency (v0.20.0) is included with default-features disabled and no explicit features enabled. This may result in missing security updates or reduced functionality. The version 0.20.0 is relatively old and may contain known vulnerabilities. Fix: Update git2 to the latest stable version (currently 0.21.x or later) and explicitly enable necessary security-related features. Review the git2 changelog for security patches.
• Medium · Multiple outdated dependencies — Cargo.toml - multiple dependencies. Several dependencies are pinned to older versions that may contain known vulnerabilities: ansi_term (0.12.1), chrono (0.4.26), and others. The bat dependency (0.26.0) is also from 2023 and may have unpatched vulnerabilities. Fix: Run 'cargo audit' to identify known vulnerabilities. Update dependencies to their latest versions while maintaining compatibility. Consider setting up dependabot or equivalent to automatically track security updates.
• Low · Audit configuration may not catch all vulnerabilities — .cargo/audit.toml. The .cargo/audit.toml file exists but its configuration is not visible. Without seeing its contents, there's no confirmation that vulnerability denial lists are properly configured or that CVSS severity thresholds are appropriate. Fix: Ensure audit.toml is configured to fail on High and Critical severity vulnerabilities. Configure deny lists for any known-vulnerable versions that cannot be immediately patched.
• Low · Unsafe regex patterns in dependencies — Cargo.toml - regex, syntect dependencies. The codebase uses regex (1.7.1) and syntect (5.0.0) which process untrusted input (diff/grep output). While Rust's regex crate is safe from ReDoS by default, syntect may have parsing vulnerabilities when processing malicious syntax definitions. Fix: Validate and sanitize external syntax definition files. Consider using a sandboxed environment for processing untrusted syntax themes. Keep syntect updated.
• Low · Shell command execution via shell-words — Cargo.toml - shell-words dependency. The shell-words (1.0.0) dependency is used for parsing shell commands. If user-supplied input is passed without proper validation, it could lead to command injection. Fix: Audit all usages of shell-words in the codebase to ensure user input is properly validated before being parsed. Use shell quoting/escaping functions appropriately.
• Low · Git repository access without explicit authentication validation — Cargo.toml - git2 dependency and source code. The git2 crate is used to access git repositories. Without seeing implementation details, there's risk of accessing repositories over insecure protocols or without proper credential handling. Fix: Ensure all git operations use secure protocols (SSH with proper key verification or HTTPS). Validate that credentials are handled securely (not logged, stored in memory only when needed, etc.).

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.