GO — Healthy across all four use cases

• Last commit 2w ago
• 19 active contributors
• Unlicense licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 81% of recent commits
• ⚠ Scorecard: default branch unprotected (0/10)

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

ripgrep (rg) is a line-oriented regex search tool written in Rust that recursively searches directories while automatically respecting .gitignore rules and filtering hidden files and binaries. It achieves 12x+ performance over competitors like grep and The Silver Searcher by combining memory-mapped I/O, SIMD optimizations, and careful parallelization, with first-class Windows, macOS, and Linux support. Monorepo with 9 workspace crates under crates/: core search engine in crates/grep and crates/searcher, gitignore handling in crates/ignore, regex compilation in crates/regex, output formatting in crates/printer, CLI argument parsing via crates/cli, and pattern matching in crates/matcher. The main binary entry point is crates/core/main.rs. Build configuration in build.rs handles feature flags (pcre2 support).

Systems engineers, developers, and DevOps practitioners who need to search large codebases (like the Linux kernel) quickly from the command line. Users who have switched from grep, ack, or ag (The Silver Searcher) and want dramatic speed improvements without learning new regex syntax.

Production-ready and actively maintained as of ripgrep 15.1.0 (Rust edition 2024, MSRV 1.85). The project has comprehensive CI/CD via GitHub Actions (ci.yml, release.yml), integration tests in tests/tests.rs, detailed documentation (GUIDE.md, FAQ.md), and a mature release process (RELEASE-CHECKLIST.md). Last activity shows ongoing development with benchmarking infrastructure and multi-year performance tracking.

Very low risk. Single maintainer (Andrew Gallant) but the codebase is mature with 8+ years of history and strong test coverage. Dependencies are minimal and well-vetted (bstr, regex, serde_json, termcolor). No evidence of security vulnerabilities or major churn. The workspace structure isolates concerns (grep, ignore, searcher, printer, matcher crates), reducing tight coupling.

Active maintenance with recent updates to Rust 2024 edition (from 2021) and MSRV bumped to 1.85. CI pipeline validates across multiple platforms. Release infrastructure exists (release.yml, RELEASE-CHECKLIST.md) for coordinated version bumps. The project maintains benchmarking data in benchsuite/runs/ with historical performance comparisons against git grep, ag, and hypergrep.

git clone https://github.com/BurntSushi/ripgrep.git
cd ripgrep
cargo build --release
./target/release/rg --version

Daily commands: For CLI: ./target/release/rg [PATTERN] [PATH] (e.g., rg 'fn main' --type rust). For development: cargo build for unoptimized, cargo build --release for performance testing. Run tests via cargo test --test integration (integration tests in tests/tests.rs). Benchmarks available via the benchsuite directory but require setup (see benchsuite/runs/*/README.SETUP).

• crates/core/main.rs — Primary entry point orchestrating CLI argument parsing, directory traversal, and regex matching pipeline.
• crates/core/flags/defs.rs — Defines all command-line flags and their configuration; essential for understanding ripgrep's CLI surface.
• crates/cli/src/process.rs — Core search execution logic handling file matching, output formatting, and parallel processing coordination.
• crates/core/haystack.rs — Abstraction for input sources (files, stdin, directories) that feeds data to the regex matcher.
• Cargo.toml — Workspace configuration defining core dependencies (regex engines, walkdir, gitignore) and version constraints.
• crates/cli/src/wtr.rs — Output writer abstraction handling results formatting, colors, and multiple output modes (JSON, CSV, plain text).
• build.rs — Build script generating completion scripts and man pages; required for full distribution builds.

• CLI Argument Parser (structopt/clap-style hand-rolled parser (defs.rs, parse.rs)) — Validates flags, normalizes paths, and builds immutable config object passed to searcher.
  • Failure mode: Invalid regex or contradictory flags fail fast with user-friendly error messages.
• Search Engine Coordinator (rayon thread pool, interior mutability for result aggregation (process.rs)) — Orchestrates parallel file processing, feeds results to output writer, handles early termination.
  • Failure mode: I/O errors on individual files are logged but don't crash; search continues on other files.
• Haystack (File Traversal) (walkdir, ignore crate, flate2/bzip2/xz2 for decompression (haystack.rs, decompress.rs)) — Abstraction over filesystem walk, stdin, and decompression; applies .gitignore and binary detection.
  • Failure mode: Permission errors skipped with debug logging; malformed .gitignore files logged as warnings.
• Regex Matcher (regex crate with DFA/NFA fallback (pattern.rs)) — Compiles patterns once, executes line-by-line matching with context capture for output.
  • Failure mode: Invalid regex patterns rejected at startup with syntax error details; too-large patterns may OOM but caught by ulimit.
• Output Writer (termcolor, serde_json, manual CSV formatting (wtr.rs, escape.rs)) — Serializes results to stdout in requested format (plain, JSON, CSV) with ANSI colors if terminal detected.
  • Failure mode: Broken pipe on stdout (e.g., piped to head) is silently caught to avoid error spam.
• Configuration Builder (Flag definitions and parse logic (flags/mod.rs, flags/defs.rs, flags/parse.rs)) — Synthesizes command-line flags into a consistent, validated config object used by searcher.
  • Failure mode: Conflicting or invalid flag combinations rejected with helpful error messages suggesting valid alternatives.
• Logging & Diagnostics (Custom log module (logger.rs)) — Emits debug, info, and error messages to stderr independent of search results.
  • Failure mode: Logging errors are swallowed; search proceeds normally.

• User Shell / Stdin → CLI Parser (main.rs) — Command-line arguments and optional stdin content for pattern matching.
• CLI Parser → Search Engine Coordinator (process.rs) — Validated config object and regex pattern ready for matching.
• Search Engine Coordinator → Haystack (file traversal) — Root directory and filter criteria; receives stream of file paths and content.
• Haystack → Regex Matcher (pattern.rs) — File content (possibly decompressed) line-by-line for pattern matching.
• Regex Matcher → Output Writer (wtr.rs) — Match results with file path, line number, and matched text.
• Output Writer → stdout / User — Formatted results in requested mode (plain text, JSON, CSV) with optional ANSI colors.

Add a new command-line flag

1. Define the flag in the flags definitions structure (crates/core/flags/defs.rs)
2. Add parsing logic for the flag (crates/core/flags/parse.rs)
3. Integrate flag into search behavior in process.rs or main.rs (crates/cli/src/process.rs)
4. Update help text template if needed (crates/core/flags/doc/template.long.help)

Add a new output format

1. Add format variant and logic to output writer (crates/cli/src/wtr.rs)
2. Define flag for the new format in flags definitions (crates/core/flags/defs.rs)
3. Implement escaping/formatting rules if needed (crates/cli/src/escape.rs)

Improve pattern matching performance

1. Optimize regex compilation or matching in pattern module (crates/cli/src/pattern.rs)
2. Profile changes using benchsuite (benchsuite/benchsuite)
3. Update search execution pipeline if needed (crates/cli/src/process.rs)

• regex crate (DFA/NFA engines) — Provides fast, safe regex matching with support for Unicode and lookahead; enables multi-threading without regex compilation per thread.
• walkdir crate — Efficient recursive directory traversal with early termination support and cross-platform path handling.
• gitignore crate (ignore) — Native .gitignore and .ignore file parsing avoiding external process calls for filtering.
• serde (JSON serialization) — Structured output formatting for machine-readable results in JSON mode.
• termcolor crate — Cross-platform colored output with Windows console support without external dependencies.

• Default respect for .gitignore rules

  • Why: Aligns ripgrep with developer expectations and Git workflows; reduces false positives in version-controlled projects.
  • Consequence: Users must use -uuu flag to search ignored files, adding cognitive overhead for power users.

• Automatic binary file detection and skipping

  • Why: Prevents noise in search results and avoids performance degradation on binary data.
  • Consequence: Cannot search binary formats directly; users must decompress or convert files first.

• Parallel per-file search using multiple CPU cores

  • Why: Maximizes throughput for large directory trees on multi-core systems.
  • Consequence: Output order is non-deterministic; some users may need --sort flag or external sorting.

• DFA-based regex engine by default

  • Why: Guarantees linear-time matching without catastrophic backtracking.
  • Consequence: Some advanced regex features (backreferences, lookarounds) require slower NFA engine or are unsupported.

• Real-time file monitoring (does not watch for file changes)
• Full replace/in-place editing (no -i flag like sed; use rg --passthru with external editors)
• Interactive selection UI (no --interactive mode like fzf integration)
• Authentication or remote file systems (local filesystem only)
• Streaming from network sources (only reads from disk and stdin)

• Avg cyclomatic complexity: ~6 — Moderate complexity: regex engine abstraction, parallel coordination, and gitignore rule application are intricate, but codebase avoids deep nesting and global state.
• Largest file: crates/core/flags/defs.rs (2,100 lines)
• Estimated quality issues: ~3 — Unwrap() calls in error paths, mutable global logger, and potential regex recompilation issues are main concerns; otherwise code is well-structured with clear separation of concerns.

• Mutable global logger state (Medium) — crates/core/logger.rs: Logger initialized once and shared globally; thread-unsafe if re-initialized mid-search.
• Unwrap-heavy error handling in process.rs (Medium) — crates/cli/src/process.rs: Multiple .unwrap() calls on file I/O operations could panic on unusual filesystem errors.
• Regex recompilation in loops (High) — crates/cli/src/pattern.rs: If pattern is recompiled per file instead of once per search, performance degrades quadratically.

• crates/cli/src/process.rs (parallel search loop) (Concurrency / I/O) — Contention on result aggregation channel when many threads emit matches simultaneously; thread pool size is fixed.
• crates/core/haystack.rs (gitignore filtering) (Algorithmic) — Every file traversal checks against potentially large .gitignore rule sets; O(rules × files) in worst case.
• crates/cli/src/wtr.rs (color output) (I/O) — ANSI color codes added per-line match; stdout syscalls accumulate on large result sets.
• crates/cli/src/decompress.rs (I/O) — Decompression happens synchronously per file; no parallelization across compressed files.

Memory allocator on musl: tikv-jemallocator is conditionally linked only for musl targets (see Cargo.toml target cfg); this reduces memory fragmentation on Linux. Edition 2024 / MSRV 1.85: new contributors must use Rust 1.85+; older toolchains will fail. Feature flag gotcha: pcre2 feature is enabled in the deb package profile but not by default in regular builds. No shell integration: rg is CLI-only; shell completions exist (FAQ.md#complete) but require separate installation. Config file parsing: ripgrep can read configuration from files, which may affect search behavior unexpectedly (check GUIDE.md#configuration-file).

• Memory-mapped I/O — ripgrep uses mmap to avoid copying entire large files into memory, enabling searches on multi-GB files with minimal overhead—critical to its speed advantage
• SIMD (Single Instruction Multiple Data) — ripgrep's custom regex crate leverages SIMD instructions (SSE, AVX, NEON) to match patterns on multiple bytes in parallel, delivering 2-5x speedups on large files
• Work-stealing parallelism — ripgrep distributes file traversal and searching across CPU cores via crossbeam/rayon work-stealing schedulers, achieving near-linear speedup on multi-core systems
• Gitignore pattern matching — ripgrep's crates/ignore crate implements full .gitignore semantics (globbing, negations, per-directory rules) to filter files before regex search, saving time on excluded paths
• Lazy evaluation in search results — ripgrep streams matches line-by-line rather than buffering all results; combined with early exit on errors, this keeps memory usage constant regardless of match count
• Context-aware line buffering — The printer crate maintains a sliding window of context lines (--before/--after flags) with minimal memory overhead, enabling efficient formatted output without re-reading files
• DFA-based regex optimization — ripgrep's regex crate compiles patterns to optimized finite automata and memoizes matches, avoiding catastrophic backtracking on pathological inputs

• ggreer/the_silver_searcher — Direct predecessor and competitor (ag); ripgrep was built to address ag's performance limitations on large codebases
• rust-lang/regex — Upstream regex engine dependency; ripgrep's crates/regex/ wraps and optimizes it with SIMD and memoization
• BurntSushi/walkdir — Related Rust utility crate by the same author for recursive directory traversal; ripgrep's ignore crate builds on similar patterns
• p-ranav/hypergrep — Modern competitor in the ripgrep benchmark suite—demonstrates alternative parallelization strategies for regex search
• Genivia/ugrep — C++ competitor in ripgrep benchmarks; ugrep achieves similar gitignore support and is used for performance comparisons

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 integration tests for gitignore behavior with nested .ignore files

The repo has comprehensive integration tests (tests/tests.rs) but lacks specific coverage for complex gitignore scenarios with multiple nested .ignore files and conflicting patterns. Given that respecting gitignore rules is a core feature advertised in the README, adding edge case tests would improve reliability and prevent regressions.

• [ ] Review existing tests in tests/tests.rs for gitignore-related test cases
• [ ] Create test fixtures in tests/ directory with nested .ignore and .gitignore files with conflicting rules
• [ ] Add integration tests covering: .ignore file precedence, negation patterns across nested directories, and interactions between .gitignore and .ignore
• [ ] Run against crates/ignore crate to verify behavior matches ignoring library expectations

Add GitHub Actions workflow for cross-platform MSRV (Minimum Supported Rust Version) testing

The Cargo.toml specifies rust-version = "1.85" as MSRV, but .github/workflows/ only contains ci.yml and release.yml. There's no dedicated CI workflow testing the actual MSRV to prevent accidental breakage. This is especially critical for a widely-used CLI tool.

• [ ] Review .github/workflows/ci.yml to understand current test matrix
• [ ] Create .github/workflows/msrv.yml that runs tests on rust-version = 1.85 specifically
• [ ] Test on multiple platforms (ubuntu-latest, windows-latest, macos-latest) as mentioned in README
• [ ] Ensure workspace members (crates/cli, crates/ignore, etc.) are all tested at MSRV

Document regex feature flags and PCRE2 usage in GUIDE.md with examples

The Cargo.toml includes a pcre2 feature flag, and the binary is compiled with it for debian packages, but GUIDE.md doesn't explain how to use PCRE2 syntax or when to enable it. New contributors and users would benefit from explicit documentation of this capability.

• [ ] Review crates/pcre2/Cargo.toml and crates/grep/Cargo.toml to understand pcre2 integration
• [ ] Add a new section to GUIDE.md titled 'Advanced: Using PCRE2 Regular Expressions'
• [ ] Include build instructions: cargo build --features pcre2
• [ ] Add 3-5 concrete examples comparing Rust regex syntax vs PCRE2 syntax differences
• [ ] Reference the pcre2 crate documentation for syntax details

• Add test coverage for the ignore crate's symlink handling—currently benchsuite/ has no automated tests for circular symlinks or broken symlinks; write integration tests in tests/tests.rs exercising symlink edge cases.
• Improve error messages in crates/cli/src/lib.rs when users provide invalid regex patterns—currently errors are generic; structured error reporting with suggestions (like 'did you mean' for common mistakes) would help beginners.
• Document the regex crate's public API in crates/regex/src/lib.rs with examples—currently sparse; add examples showing how to use the custom regex wrapper for library consumers outside ripgrep itself.

ripgrep demonstrates a generally secure codebase with dual licensing (MIT/Unlicense), no hardcoded credentials detected, and no obvious injection vulnerabilities in the file structure. The main concerns are: (1) an invalid Rust edition configuration that should be corrected, (2) debug symbols in release builds which could be optimized, (3) typical ReDoS risks associated with regex processing that require ongoing dependency monitoring, and (4) standard path traversal considerations for a filesystem traversal tool. No Docker/infrastructure issues, exposed secrets, or critical architectural flaws were identified. The codebase follows Rust best practices with workspace organization and proper dependency management.

• Medium · Outdated Rust Edition Declaration — Cargo.toml - edition field. The Cargo.toml specifies edition = '2024', which does not exist. The latest stable Rust edition is 2021. This appears to be a configuration error that could cause build failures or unexpected behavior. Fix: Update edition to '2021' or the appropriate stable edition supported by the configured rust-version (1.85)
• Low · Debug Symbols in Release Build — Cargo.toml - [profile.release] section. The release profile includes 'debug = 1', which includes debug symbols in production binaries. While this aids debugging, it increases binary size and could potentially expose internal structure information. Fix: Consider setting debug = 0 for production releases unless debugging is required, or use the release-lto profile which sets debug = 'none'
• Low · Regex Dependency Security — Cargo.toml - grep dependency and crates/regex. The crate uses regex functionality through the grep crate. Regex denial-of-service (ReDoS) vulnerabilities are a known risk class. While the grep crate is maintained, ensure regular dependency updates. Fix: Maintain regular updates of regex-related dependencies and monitor for ReDoS advisories via 'cargo audit'
• Low · File Path Traversal Potential — crates/ignore and crates/cli modules. As a file search tool that recursively traverses directories, ripgrep processes user-controlled paths. While the tool respects .gitignore, symlinks and path traversal could be vectors if input validation is insufficient. Fix: Review symlink handling policies and ensure proper canonicalization of paths to prevent directory traversal attacks

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

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

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. Read in the suggested order before editing unfamiliar code. The reading-order list is computed from the actual import graph, not LLM guesses; reading bottom-up materially reduces wrong-edit risk.
3. 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.
4. Cite source on changes. When proposing an edit, cite the specific path/to/file.ext:Lstart-Lend you're reasoning about, the same way RepoPilot's own RAG cites code in https://repopilot.app/r/BurntSushi/ripgrep.

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.

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

What it runs against: a local clone of BurntSushi/ripgrep — 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 BurntSushi/ripgrep | Confirms the artifact applies here, not a fork | | 2 | License is still Unlicense | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 43 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of BurntSushi/ripgrep. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/BurntSushi/ripgrep.git
#   cd ripgrep
#
# 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 BurntSushi/ripgrep and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f "crates/core/main.rs" \\
  && ok "crates/core/main.rs" \\
  || miss "missing critical file: crates/core/main.rs"
test -f "crates/core/flags/defs.rs" \\
  && ok "crates/core/flags/defs.rs" \\
  || miss "missing critical file: crates/core/flags/defs.rs"
test -f "crates/cli/src/process.rs" \\
  && ok "crates/cli/src/process.rs" \\
  || miss "missing critical file: crates/cli/src/process.rs"
test -f "crates/core/haystack.rs" \\
  && ok "crates/core/haystack.rs" \\
  || miss "missing critical file: crates/core/haystack.rs"
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 43 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~13d)"
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/BurntSushi/ripgrep"
  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).

Computed from the actual import graph (no LLM). Read in this order to learn the codebase from the foundation up — each step builds on the previous ones.

1. crates/cli/src/decompress.rs — Foundation: doesn't import anything internally and is imported by 1 other file. Read first to learn the vocabulary.
2. crates/cli/src/escape.rs — Foundation: imported by 1, no internal dependencies of its own.
3. crates/core/flags/mod.rs — Built on the foundation; imported by 1 downstream file.
4. crates/searcher/src/searcher/mod.rs — Built on the foundation; imported by 1 downstream file.
5. crates/printer/src/lib.rs — Layer 2 — application-level code that wires the lower layers together.

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