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/arxanas/git-branchless 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 today
• 12 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 55% of recent commits

_{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 arxanas/git-branchless repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/arxanas/git-branchless.

What it runs against: a local clone of arxanas/git-branchless — 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 arxanas/git-branchless | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | 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 ≤ 30 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 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 "git-branchless-lib/src/lib.rs" \\
  && ok "git-branchless-lib/src/lib.rs" \\
  || miss "missing critical file: git-branchless-lib/src/lib.rs"
test -f "git-branchless-lib/src/core/mod.rs" \\
  && ok "git-branchless-lib/src/core/mod.rs" \\
  || miss "missing critical file: git-branchless-lib/src/core/mod.rs"
test -f "git-branchless-lib/src/core/dag.rs" \\
  && ok "git-branchless-lib/src/core/dag.rs" \\
  || miss "missing critical file: git-branchless-lib/src/core/dag.rs"
test -f "git-branchless-lib/src/core/rewrite/execute.rs" \\
  && ok "git-branchless-lib/src/core/rewrite/execute.rs" \\
  || miss "missing critical file: git-branchless-lib/src/core/rewrite/execute.rs"
test -f "git-branchless-lib/src/git/repo.rs" \\
  && ok "git-branchless-lib/src/git/repo.rs" \\
  || miss "missing critical file: git-branchless-lib/src/git/repo.rs"

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

git-branchless is a Git workflow enhancement suite written in Rust that implements a commit-graph-based development model as an alternative to traditional branch-based workflows. It provides high-velocity tools like git undo (reversible history), git smartlog (DAG visualization), git restack (automatic conflict resolution), and speculative merges for monorepo-scale development without requiring branches. The core innovation is treating commits as first-class entities in a directed acyclic graph (DAG) managed by Sapling's eden_dag library. Workspace monorepo with 15 interconnected crates: git-branchless-lib (core engine), git-branchless (CLI entrypoint), plus specialized modules like git-branchless-move, git-branchless-smartlog, git-branchless-undo, git-branchless-record for distinct features. Init/hook/invoke crates handle Git integration. scm-bisect is a utility library. The Sapling DAG (eden_dag dependency) provides the underlying commit graph data structure.

Software engineers and teams working in monorepos or managing complex Git histories who want faster, more intuitive workflows; particularly valuable for contributors managing stacked commits, frequent rebases, or non-linear development. Power users frustrated with branch management overhead and developers seeking Git undo/redo capabilities.

Production-ready and actively maintained. The project has comprehensive CI coverage across Linux/macOS/Windows (see .github/workflows/), multiple workspace crates with tests, Nix support, and multi-platform release automation. Changelog and semantic versioning (currently 0.10.0) indicate active development with stability focus. Not experimental—used in real monorepo environments.

Low risk for stable users; moderate risk for cutting-edge adopters. Dependencies are well-maintained (cursive TUI, git2, chrono) and the 2M+ LOC Rust codebase has comprehensive CI. Single maintainer (arxanas) is a potential concern for long-term support. Breaking changes appear documented in CHANGELOG.md. The DAG-based model is novel enough that edge cases in complex workflows may exist.

Active release cycle (v0.10.0 workspace version visible in dependencies). Multi-platform CI pipelines running on every push (lint, Linux, macOS, Windows, Nix variants). Dependabot enabled for dependency updates. Discussions and Discord community indicate ongoing user engagement. Recent work appears focused on stability and cross-platform compatibility given the breadth of CI configs.

git clone https://github.com/arxanas/git-branchless.git
cd git-branchless
cargo build --release
cargo install --path git-branchless

Requires Rust toolchain (Cargo.toml present). Optionally use Nix: nix develop (flake.nix present). Optional: open in Gitpod via .gitpod.yml for browser-based dev.

Daily commands: Build: cargo build (dev) or cargo build --release (optimized). Install locally: cargo install --path git-branchless. Run tests: cargo test (all crates). Interactive dev: after install, use git undo, git smartlog, git move, etc. as Git subcommands. Dev server: No traditional server; this is a Git extension. Use .devcontainer/ or .gitpod.yml for containerized development environments.

• git-branchless-lib/src/lib.rs — Main library entry point exposing core git-branchless functionality to all CLI tools and external consumers
• git-branchless-lib/src/core/mod.rs — Core module orchestrator containing the primary abstractions for DAG manipulation, event logging, and rewrite operations
• git-branchless-lib/src/core/dag.rs — Directed acyclic graph implementation that represents commit relationships and is fundamental to branchless workflow logic
• git-branchless-lib/src/core/rewrite/execute.rs — Executes commit rewrites (cherry-pick, rebase) across the DAG and coordinates with git's low-level operations
• git-branchless-lib/src/git/repo.rs — Rust wrapper around libgit2 providing the abstraction layer for all Git repository interactions
• git-branchless-lib/src/core/eventlog.rs — Event logging system tracking user actions and Git state changes for undo/redo and audit capabilities
• Cargo.toml — Workspace configuration defining 17 member crates with their interdependencies and shared configuration

Add a new Git subcommand (e.g., git branchless foobar)

1. Create new member crate in workspace (Cargo.toml (add to [workspace] members))
2. Implement CLI argument parser and entry point (git-branchless-<subcommand>/src/main.rs)
3. Implement command logic using git-branchless-lib abstractions (git-branchless-<subcommand>/src/lib.rs)
4. Wire command into main dispatcher or git alias (git-branchless/src/main.rs or .git/config)
5. Add integration tests (git-branchless-<subcommand>/tests/test_*.rs)

Add a new rewrite strategy (e.g., new cherry-pick variant)

1. Define the strategy and planning logic (git-branchless-lib/src/core/rewrite/plan.rs)
2. Implement execution with conflict resolution (git-branchless-lib/src/core/rewrite/execute.rs)
3. Update evolution logic if descendants are affected (git-branchless-lib/src/core/rewrite/evolve.rs)
4. Add integration test with DAG snapshots (git-branchless-lib/tests/test_rewrite_evolve.rs)

Add a new git-config option for branchless

1. Define config schema and defaults (git-branchless-lib/src/core/config.rs)
2. Parse option in initialization or command handler (git-branchless-init/src/main.rs or relevant CLI command)
3. Use config value in decision logic (git-branchless-lib/src/core/rewrite/execute.rs or other core module)
4. Add test case with fixture (git-branchless-lib/tests/test_repo.rs)

Add a new Git hook event or modify event capture

1. Update hook script or libgit2 callback registration (git-branchless-hook/src/main.rs)
2. Define event variant in eventlog schema (git-branchless-lib/src/core/eventlog.rs)
3. Add serialization/deserialization for persistence (git-branchless-lib/src/core/eventlog.rs (serde impl))
4. Test hook invocation and event logging (git-branchless-hook/tests/test_hook.rs)

• Rust — Type-safe, high-performance Git operations without GC pauses; critical for tool reliability in monorepo workflows
• libgit2 — Direct Git object manipulation without spawning git binary; enables transactional commit rewrites and DAG analysis
• Event sourcing (eventlog) — Enables reliable undo/redo by replaying state changes; supports offline operation and auditing
• Git hooks (post-commit, post-rewrite) — Captures state changes without modifying Git's core; compatible with traditional Git workflows
• Cargo workspace — Modular architecture with 17 crates allows independent CLI tools sharing core library; reduces binary bloat

No exposed .rs file tree: File list truncated at crate level; must cargo build to see actual module structure. Git state directory: Branchless uses .git/branchless/ for persisting state; tests may fail if this is not writable or cleared between runs. Sapling DAG abstraction: The eden_dag (sapling-dag) crate is external and its API may have subtle version constraints—check Cargo.lock if DAG operations fail. Hook execution order: Git hooks are critical for syncing state; if hooks don't run (e.g., user disables core.hooksPath), history can diverge from Git refs. Interactive TUI blocking: Cursive UI operations are blocking; long-running Git operations may freeze the terminal. Monorepo install: Installing just one subcrate (e.g., cargo install --path git-branchless-move) may not work correctly without the lib crate; always install from workspace root. Cross-platform path handling: Uses Rust Path abstractions but Git on Windows expects / slashes—subtle bugs possible in hook generation.

• Directed Acyclic Graph (DAG) for commit history — git-branchless models commit history as a DAG (via Sapling's eden_dag) rather than a linear branch sequence; understanding DAG traversal, topological sorting, and ancestor/descendant relationships is core to how restack, undo, and move operations function.
• Revsets (revision sets) — git-branchless-query uses revset expressions (inherited from Sapling/Mercurial) to filter and select commits (e.g., 'only(main)' or 'children(my-commit)'); mastering revsets unlocks powerful querying without learning branch names.
• Post-receive Git hooks and ref updates — git-branchless-hook intercepts Git operations (post-checkout, post-merge, post-rewrite) to maintain branchless state; understanding Git's hook architecture is essential for debugging sync issues and extending the tool.
• Interactive rebase and conflict resolution — git-branchless uses interactive rebasing (via git rebase --interactive) and cursive TUI to guide users through conflicts; understanding how --exec, --no-verify, and GIT_EDITOR interact is critical for fixing broken workflows.
• Stacked commits (patch stack workflow) — The core branchless paradigm treats a PR or feature as a stack of logically independent commits rather than a branch; understanding how to author, reorder, and amend stacks is central to the tool's value proposition.
• Rust workspace and workspace.dependencies — git-branchless is a 15-crate Rust workspace with shared dependency versions via [workspace.dependencies]; understanding how Cargo workspaces compile and share configuration is necessary for building and modifying the project.
• Speculative merges (pre-merge conflict detection) — git-branchless offers speculative merges to detect conflicts before actually merging; this is a novel feature that requires understanding merge base computation and three-way merge semantics.

• jj-vcs/jj — Jujutsu is a Git-compatible VCS built on similar DAG principles (also inspired by Sapling); serves as a conceptual cousin and alternative for users wanting a full VCS replacement rather than a Git wrapper.
• facebook/sapling — Sapling is the parent project that git-branchless builds upon (eden_dag dependency); understanding Sapling's DAG and revset language is essential context for this tool's graph operations.
• gitless/gitless — Gitless provides a similar high-level abstraction over Git with simplified workflows; an alternative approach to reducing Git complexity (though more opinionated than git-branchless).
• emacs-evil/evil — Not directly related but git-branchless integrates with text editors (Vim, Emacs via hooks); Evil mode users may find complementary workflow docs.

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 git-branchless-hook post-commit behavior

The git-branchless-hook crate (git-branchless-hook/src/main.rs and lib.rs) only has one test file (git-branchless-hook/tests/test_hook.rs). Given that hooks are critical for the branchless workflow, there should be comprehensive integration tests covering hook interactions with different git operations (amend, rebase, cherry-pick). This would catch regressions early and document expected hook behavior.

• [ ] Review git-branchless-hook/tests/test_hook.rs to understand current test coverage
• [ ] Add integration tests for post-commit hook behavior with git amend operations
• [ ] Add integration tests for post-commit hook behavior with git rebase operations
• [ ] Add integration tests for hook failures and edge cases (detached HEAD, merge conflicts)
• [ ] Run tests locally with cargo test -p git-branchless-hook to verify

Add CI workflow for dependency audit and security scanning

The repo has extensive CI workflows (linux.yml, windows.yml, macos.yml, nix-* variants) but lacks a dedicated security/dependency audit workflow. Given this is a Git workflow tool that developers depend on, adding cargo-audit or cargo-deny checks would catch vulnerable dependencies before release and is a best practice for security-sensitive projects.

• [ ] Create .github/workflows/security-audit.yml
• [ ] Configure cargo-audit to scan Cargo.lock for known vulnerabilities
• [ ] Add cargo-deny for license compliance checking (given the dual Apache/MIT licensing)
• [ ] Set workflow to trigger on: push to main, pull_requests, and weekly schedule
• [ ] Reference the existing release.yml workflow for CI patterns

Add comprehensive documentation for git-branchless-lib public API in lib/README.md

While git-branchless-lib/README.md exists, it's minimal. The library crate exposes public modules (git-branchless-lib/src/core/check_out.rs and others) that are used by consumer crates in the workspace, but there's no API documentation guide. Adding module-level documentation with examples would help contributors understand how to use and extend the library.

• [ ] Review git-branchless-lib/src/lib.rs to identify public modules and key types
• [ ] Expand git-branchless-lib/README.md with API overview section
• [ ] Document the core module structure (core/check_out.rs, etc.) and their responsibilities
• [ ] Add code examples for common library usage patterns (querying commits, checking out, etc.)
• [ ] Add a 'Contributing to git-branchless-lib' section referencing CONTRIBUTING.md patterns

• Add missing test coverage for git-branchless-record/src/: The record crate is present in the workspace but has no visible tests directory in the file list; writing integration tests for the staging/recording logic would improve robustness and serve as learning material for how the undo/record flow works.
• Improve documentation for the DAG model and commit graph concepts: The README mentions 'commit graphs' and 'branchless workflows' but the core DAG concepts (using Sapling's eden_dag) lack a technical deep-dive in the docs; adding architecture docs in a ARCHITECTURE.md file or wiki would help onboarding.
• Extend git-branchless-query with examples for revset filtering: The query crate exists (visible in Cargo.toml) but no examples/ or demo files show real revset usage patterns; adding demo scripts (similar to demos/demo_*.sh pattern) for common queries would be high-impact for discoverability.

The git-branchless codebase demonstrates generally good security practices with proper use of Rust's memory safety guarantees and a well-structured CI/CD pipeline. However, potential risks exist around command injection in Git operations, dependency management, and Docker configuration hardening. The primary concerns are: (1) ensuring all git command invocations properly validate user input, (2) maintaining up-to-date and audited dependencies, and (3) hardening container configurations. The absence of visible hardcoded secrets and proper use of licensing files is positive. No critical vulnerabilities were identified based on the available file structure and configuration snippets.

• Medium · Potential Command Injection in Git Operations — git-branchless-lib/src/core, git-branchless-lib/src/git/. The codebase appears to interact extensively with Git operations through shell commands and external processes. Without visible input validation in the file structure, there's a risk of command injection if user-provided arguments are not properly sanitized before being passed to git commands. Fix: Ensure all user inputs are validated and sanitized before being used in git commands. Use Rust's built-in git libraries (libgit2 via rust-git2) instead of shell invocations where possible. Implement strict argument parsing and avoid string interpolation for command construction.
• Medium · Use of Potentially Vulnerable External Dependencies — Cargo.toml, workspace dependencies. The workspace includes direct use of 'cursive' UI library and multiple dependencies without visible lock file verification in CI/CD. The dependency 'chashmap' (v2.2.2) is a concurrent hashmap that may have alternative, more actively maintained solutions. Fix: Regularly audit dependencies using 'cargo audit'. Consider replacing 'chashmap' with 'dashmap' which is more actively maintained. Implement dependency vulnerability scanning in the CI/CD pipeline (which appears to exist but should verify all transitive dependencies).
• Low · Hardcoded Version Strings Across Workspace — Cargo.toml, all package dependencies (git-branchless-hook, git-branchless-init, etc.). Version '0.10.0' is hardcoded across all workspace members. This could lead to version mismatch issues if manual updates are missed during releases. Fix: Use workspace-level version management with '[workspace.package]' section in Cargo.toml to define version once and reference it across all members, reducing manual synchronization errors.
• Low · Missing Security Headers in Docker Configuration — .devcontainer/Dockerfile, .gitpod/Dockerfile. Dockerfile configurations in .devcontainer and .gitpod do not show evidence of security hardening such as running containers as non-root users or implementing minimal base images. Fix: Implement security best practices: use non-root user (USER directive), run with minimal base images (e.g., 'rust:slim'), use multi-stage builds to minimize attack surface, and scan docker images regularly with tools like 'trivy' or 'snyk'.
• Low · Potential Information Disclosure via Debugging Features — git-branchless-lib/bin/testing/. Profile and testing binaries are included in the repository (git-branchless-lib/bin/testing/). These development tools could expose sensitive information if deployed to production environments. Fix: Exclude testing and profiling binaries from release builds. Implement conditional compilation with feature flags to ensure these tools are only compiled when explicitly enabled for development purposes.
• Low · Dependency on Event Logging Without Visible Output Validation — git-branchless-lib/src/core/eventlog.rs. The 'eventlog' module (git-branchless-lib/src/core/eventlog.rs) may handle sensitive Git operation history. Without visible output encoding/escaping, there could be injection risks in log output. Fix: Ensure all eventlog outputs are properly escaped and validated. Implement structured logging with proper encoding for special characters. Review logging output for sensitive information (commit hashes, author details) that might aid attackers.

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.