WAIT — Stale — last commit 2y ago

• 7 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Single-maintainer risk — top contributor 91% of recent commits

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

Git History is a tool that lets you browse the complete commit history of any file in GitHub, GitLab, or Bitbucket by simply replacing the domain name (e.g., github.com → github.githistory.xyz). It fetches all commits affecting a file, displays diffs with syntax highlighting via Prism, and animates between versions to show how the code evolved over time. Monorepo with two main parts: (1) React frontend in src/ with git-providers/ abstraction layer supporting GitHub/GitLab/Bitbucket/CLI, (2) Node CLI in cli/ that builds and serves the React app locally. Core logic splits between commit fetchers (e.g., github-commit-fetcher.js), differ.js for diff computation, and versioner for timeline generation. Animation logic in src/animation.js and src/airframe/.

Developers who need to understand how a specific file changed over time without cloning repos or using git locally. Used by code reviewers investigating file history on hosted platforms, and by learners studying how real-world projects evolved. Also used via CLI/VS Code extension by local development workflows.

Actively maintained and production-ready. The project has a CI pipeline (.travis.yml), browser extensions in Chrome and Firefox webstores, a dedicated CLI, and a VS Code extension. Monorepo structure supports multiple deployment targets (web, CLI, local). Clear governance with a Patreon/OpenCollective sponsorship model.

Single maintainer (pomber) creates sustainability risk for a widely-used tool. Dependencies are modest (~9 in CLI, mostly Koa/yargs) but pinned to older versions (Koa 2.7.0, yargs 13.2.2 from 2019). API rate-limiting from GitHub/GitLab/Bitbucket could throttle large file histories. No visible test suite for git providers or diff logic, only language-detector.test.js present.

Repository contains infrastructure for multi-platform support (extensions, CLI, web). .github/FUNDING.yml and opencollective.yml indicate ongoing sponsorship efforts. Storybook config present for component development. No recent commit data visible, but structure suggests focus is on stability and platform integration rather than new features.

git clone https://github.com/pomber/git-history.git && cd git-history && yarn install && yarn start (for React dev server). For CLI development: cd cli && yarn install && yarn start. See cli/readme.md for CLI-specific setup.

Daily commands: Frontend dev: yarn start (CRA dev server). CLI: cd cli && node cli.js --repo=<url> --file=<path>. Production: yarn build-site builds React app and copies to cli/site/ for CLI distribution. Netlify deployment configured in netlify.toml.

• src/app.js — Main React application entry point; orchestrates git provider selection, history fetching, and UI rendering
• src/git-providers/providers.js — Central registry that routes requests to GitHub, GitLab, Bitbucket, CLI, or VSCode providers based on source detection
• src/git-providers/versioner.js — Core logic that parses git commit history and builds the change timeline; used by worker thread for performance
• cli/server.js — CLI server that serves the web UI and acts as middleware between browser requests and local git repositories
• src/history.js — Manages state and lifecycle of file history data; bridges providers to UI components
• src/git-providers/differ.js — Computes textual diffs between file versions; critical for accurate change visualization
• src/scroller.js — Interactive timeline scrubber UI component; handles animation and version navigation

Add Support for a New Git Hosting Provider

1. Create a new provider file following the pattern of github-provider.js at src/git-providers/your-provider.js with fetchFileContent() and fetchCommits() methods (src/git-providers/your-provider.js)
2. Export your provider as a named export and register it in the providers.js switch statement (src/git-providers/providers.js)
3. Add URL detection logic to sources.js to identify your provider's domain in the git URL (src/git-providers/sources.js)
4. Test by passing a file URL from your provider to the app; verify it routes to your provider correctly

Add a New Animation or Transition

1. Define easing function or keyframe animation in src/animation.js or src/airframe/easing.js (src/animation.js)
2. Use the spring API from use-spring.js or CSS transitions in your target component (e.g., scroller.js) (src/use-spring.js)
3. Test animation smoothness and performance; adjust spring tension/friction in use-spring.js if needed

Improve Diff or Version Timeline Calculation

1. Modify the versioner.js algorithm to change how file versions are extracted from commit history (src/git-providers/versioner.js)
2. Update the differ.js logic if changing how textual changes between versions are computed (src/git-providers/differ.js)
3. Test with versioner.test.js and utils.test.js to ensure timeline correctness and performance (src/git-providers/versioner.js)

Add a New CLI Feature or Server Route

1. Add argument parsing in cli/cli.js using yargs for new CLI flags or commands (cli/cli.js)
2. Implement request handling in cli/server.js; add a new Koa route if serving a new endpoint (cli/server.js)
3. Use cli/git.js to interact with local git repositories via execa if your feature requires git data

• React — Declarative UI for responsive history timeline and commit visualization; component reuse for different provider UIs
• Web Workers (versioner.worker.js) — Long-running history parsing (up to 5s for large repos) runs off-thread to keep UI responsive
• Koa + koa-router + koa-static — Lightweight Node.js server for CLI mode; minimal overhead for serving static web UI and proxying to local git
• execa (for git commands) — Safe subprocess execution of git commands without shell injection risks; used by CLI and VSCode providers
• GitHub/GitLab/Bitbucket REST APIs — Direct API access for browser-based history without requiring local git clone; enables instant cross-platform browsing

• Web Worker for versioner.js instead of streaming/pagination

  • Why: Simplifies logic: build entire timeline once rather than incremental updates
  • Consequence: High latency for very large histories (>10k commits); UI freeze risk on slow machines until worker completes

• Store full file content in memory for each version

  • Why: Enables instant scrubbing without re-fetching; smooth animations
  • Consequence: Memory overhead scales with repo size; large binaries or many versions can exhaust browser memory

• Support multiple providers (GitHub, GitLab, Bitbucket, CLI, VSCode) via pluggable abstraction

  • Why: Maximizes usability; users can browse history directly from any git host
  • Consequence: Higher maintenance burden; each provider API change requires code update; rate-limiting varies by host

• Client-side rendering + browser storage (localStorage) instead of server-side caching

  • Why: No central server needed; works offline once history is fetched; privacy (no server logs)
  • Consequence: Limited to browser storage capacity (~5–50MB); cache invalidation relies on user clearing cache

• Does not persist history data server-side; each browse session refetches from git host
• Does not support authentication beyond public/unauthenticated API access (CLI mode supports SSH keys)
• Does not perform code analysis or AI-powered insights; strictly a visualization tool
• Does not handle merge conflict resolution or multi-branch history
• Does not support real-time collaborative history browsing

REACT_APP_GIT_PROVIDER env var (set in build-site script) selects which provider is baked into the built artifact—CLI uses 'cli' provider, web uses 'github'. Versioner runs in a Web Worker; changes to diff logic may need both main thread and worker updates. Large files > 10k commits may hit API rate limits (no built-in batching visible). CLI expects local git to be available (cli/git.js spawns git commands). No visible environment variable docs for GitHub/GitLab/Bitbucket tokens.

• Git plumbing vs porcelain — cli/git.js spawns low-level git commands (git log --format, git show) rather than high-level porcelain; understanding raw output format is key to parsing commits correctly
• Three-way/unified diff format — differ.js parses unified diff output from git; knowing hunk headers (@@ -a,b +c,d @@) and line prefixes (+/-/ ) is essential to fixing diff bugs
• Web Workers for long-running computation — versioner.worker.js offloads diff processing to background thread so UI stays responsive for large file histories; modifying diff logic requires understanding worker message passing
• Request adapter pattern (multiple Git providers) — src/git-providers/ uses adapter pattern to abstract away GitHub/GitLab/Bitbucket API differences; adding a new platform requires understanding this abstraction
• Easing functions for animation — src/airframe/easing.js defines curves (ease-in-out, cubic, etc.) that smooth transitions between file versions; tweaking perceived performance requires understanding easing math
• Syntax tree parsing with Prism — duotoneLight.js configures Prism tokenizer for code highlighting; extending language support or tweaking colors requires Prism token understanding
• Content Security Policy for browser extensions — Browser extensions inject git-history UI into GitHub/GitLab/Bitbucket pages; extension manifests must declare CSP and host permissions correctly to avoid injection failures

• git/git — Upstream source; git-history wraps git plumbing commands (git log, git show, git diff) exposed via CLI
• Wilfred/difftastic — Alternative structured diff engine (Rust-based) that could replace differ.js for semantic diffs instead of line-based
• pomber/commit-terminal — Sibling project by same author; terminal-based alternative to git-history for local repos
• PrismJS/prism — Dependency for syntax highlighting; git-history customizes theme in duotoneLight.js
• facebook/create-react-app — Build tooling foundation; git-history uses CRA with Craco config overrides for non-ejected customization

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 tests for git-providers/differ.js and language-detector.js

The codebase has only one test file (language-detector.test.js) and lacks tests for critical modules like differ.js which handles the core diff functionality across multiple git providers (GitHub, GitLab, Bitbucket). This is high-value because differ.js is central to the product's functionality and currently has no test coverage. Adding tests here would catch regressions across different provider implementations.

• [ ] Create src/git-providers/differ.test.js with test cases for different diff formats from GitHub, GitLab, and Bitbucket APIs
• [ ] Expand src/git-providers/language-detector.test.js with edge cases (binary files, mixed languages, unknown extensions)
• [ ] Add tests for src/git-providers/versioner.js to ensure correct commit ordering and version tracking
• [ ] Run tests in CI/CD pipeline (see next suggestion)

Add GitHub Actions workflow for automated testing and CLI validation

The repo uses Travis CI (.travis.yml exists) but lacks a modern GitHub Actions workflow. There's no visible test execution pipeline, and the CLI component (cli/cli.js, cli/git.js, cli/server.js) has no automated validation. Adding a workflow would catch breaking changes in the CLI interface and ensure the build-site script works correctly across commits.

• [ ] Create .github/workflows/test.yml to run npm test in cli/ and root directories
• [ ] Add validation step to verify cli/site/ builds correctly with 'yarn build-site'
• [ ] Test the three CLI entrypoints (git-file-history, githistory, git-history) with sample git operations
• [ ] Add code coverage reporting to catch untested code in git-providers and src/

Refactor and document the git-providers plugin system with a provider template

There are 4 provider implementations (GitHub, GitLab, Bitbucket, CLI) with similar but duplicated patterns in their -provider.js and -commit-fetcher.js files. The src/git-providers/providers.js registry exists but lacks documentation. Adding a documented template and refactoring common logic would reduce maintenance burden and make it easier for contributors to add new providers (e.g., Gitea, Gitee).

• [ ] Create src/git-providers/PROVIDER_TEMPLATE.md documenting the required interface (getFile, getCommits, getBlameData methods)
• [ ] Extract common request/auth logic from github-provider.js and gitlab-provider.js into src/git-providers/provider-utils.js
• [ ] Add JSDoc comments to all exported functions in src/git-providers/providers.js and sources.js explaining the provider registration flow
• [ ] Create an example provider (e.g., src/git-providers/example-provider.js) following the new template as a reference implementation

• Add test coverage for differ.js: currently no .test.js file; write tests verifying diff hunks are correctly extracted from git diffs (use real commit hashes from test repos).
• Document token configuration: Add env var examples (GITHUB_TOKEN, GITLAB_TOKEN, BITBUCKET_TOKEN) to cli/readme.md and src/git-providers/ to guide users on API auth for rate-limit avoidance.
• Implement language detection for missing types: language-detector.js likely has gaps; extend it with test cases in language-detector.test.js for Rust, Go, Kotlin (check which .githistory.xyz users hit most).

• High · Outdated Dependencies with Known Vulnerabilities — cli/package.json. Multiple dependencies are pinned to outdated versions that may contain known security vulnerabilities. Specifically: execa@1.0.0, get-port@4.1.0, koa@2.7.0, koa-router@7.4.0, koa-static@5.0.0, open@0.0.5, and yargs@13.2.2 are all significantly outdated (2-5+ years old). These versions likely have unpatched CVEs. Fix: Update all dependencies to their latest stable versions. Run 'npm audit' to identify specific vulnerabilities and address them. Implement automated dependency scanning in CI/CD pipeline.
• High · Insecure Open Package Version — cli/package.json, cli/server.js. The 'open' package is pinned to version 0.0.5, which is an extremely old version from 2013. This package is used to open URLs/files and may have command injection vulnerabilities. Fix: Update 'open' to the latest version (v9.x or later). Validate and sanitize all inputs passed to the open() function to prevent command injection attacks.
• High · Unsafe Command Execution with execa — cli/git.js, vscode-ext/git.js. The 'execa' package (v1.0.0) is used for executing git commands. If user input or file paths are not properly sanitized before being passed to git commands, this could lead to command injection vulnerabilities. Fix: Validate and sanitize all inputs before passing to execa. Use parameterized/escaped arguments. Never directly interpolate user input into shell commands. Update execa to latest version.
• Medium · Missing Content Security Policy Headers — cli/server.js. The application serves web content but there's no evidence of CSP headers being configured in server.js or middleware. This increases XSS attack surface. Fix: Implement Content Security Policy headers in the Koa middleware. Set appropriate directives like default-src, script-src, style-src to restrict resource loading.
• Medium · Unvalidated External Git Repository Access — src/git-providers/github-provider.js, src/git-providers/gitlab-provider.js, src/git-providers/bitbucket-provider.js. The application allows users to specify arbitrary git repositories (GitHub, GitLab, Bitbucket). Without proper validation, this could be exploited for SSRF attacks or accessing private repositories if credentials are improperly handled. Fix: Implement URL validation to ensure only legitimate git repository URLs are processed. Implement rate limiting. Use OAuth tokens securely without hardcoding. Validate all external API responses.
• Medium · Potential XSS via Dynamic Content Rendering — src/git-providers/differ.js, src/slide.js, src/scroller.js. The application renders git file contents and diffs dynamically. If content is not properly escaped, especially in src/git-providers/differ.js and related components, XSS attacks are possible. Fix: Ensure all dynamically rendered content is properly HTML-escaped. Use React's built-in escaping mechanisms and avoid dangerouslySetInnerHTML. Sanitize syntax-highlighted code output.
• Medium · Insecure Default Port Assignment — cli/server.js, cli/cli.js. The application uses get-port to find available ports dynamically. Without explicit port restrictions or firewall rules, the server could bind to unintended ports. Fix: Implement explicit port configuration with reasonable defaults. Document security implications. Consider binding to localhost (127.0.0.1) by default instead of all interfaces.
• Low · Missing Security Headers — cli/server.js. No evidence of security headers (X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security) in the Koa server configuration. Fix: Add middleware to set security headers: X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Strict-Transport-Security, X-XSS-Protection.
• Low · undefined — undefined. undefined Fix: undefined

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. 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/pomber/git-history 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.

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

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "pomber/git-history(\\.git)?\\b" \\
  && ok "origin remote is pomber/git-history" \\
  || miss "origin remote is not pomber/git-history (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "src/app.js" \\
  && ok "src/app.js" \\
  || miss "missing critical file: src/app.js"
test -f "src/git-providers/providers.js" \\
  && ok "src/git-providers/providers.js" \\
  || miss "missing critical file: src/git-providers/providers.js"
test -f "src/git-providers/versioner.js" \\
  && ok "src/git-providers/versioner.js" \\
  || miss "missing critical file: src/git-providers/versioner.js"
test -f "cli/server.js" \\
  && ok "cli/server.js" \\
  || miss "missing critical file: cli/server.js"
test -f "src/history.js" \\
  && ok "src/history.js" \\
  || miss "missing critical file: src/history.js"

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

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