gitmole

A toolkit for digging into any cloned git repository: who works on it, where the risk is, how old the code is, whether the repo itself is healthy, and whether anything sensitive was ever committed.

Free. Any Stack. Local. Offline. Deterministic. Fast.

• Free. MIT licence, no paid tier, no account, no token. A local clone needs no credentials, and a public owner/repo is cloned with plain git. Your gh login is only used for private repositories and for owner/*, and only when you ask for them. The tools it runs are open source too.
• Any stack. It reads what every repository has: the git log, git blame and the files themselves.
• Local & Offline. Everything runs against a clone on your machine. Nothing is uploaded, nothing phones home; the vulnerability database is a copy you download once.
• Deterministic. No AI at runtime. Every finding is a plain rule over counts you can recompute by hand. The JSON export carries each finding's rule, the numbers it fired on and, where a rule rests on a paper, the citation. The same commit gives the same bytes: gitmole's own CI runs it twice on every commit, compares the exports and attests the report.

Install

# macOS, or Linux with Homebrew: gitmole and the five tools it runs
brew tap antvinni/gitmole https://github.com/antvinni/gitmole
brew trust antvinni/gitmole
brew install gitmole

# anywhere else: scc, git-sizer, betterleaks, jscpd and osv-scanner on your PATH, then
pipx install gitmole

Linux package names, the release binaries, --plots and the pip caveats: docs/install.md.

Usage

gitmole .                              # the clone you are in
gitmole /path/to/clone                 # any local clone
gitmole owner/repo                     # clones into a temp dir first, with gh or plain git
gitmole 'owner/*'                      # every non-archived repo of a user or org, one summary table

gitmole . --markdown report.md         # the same report as a Markdown document
gitmole . --json report.json           # every table, the watch list and the findings
gitmole . --fail-on warning            # exit 3 if any finding is a warning or worse
gitmole . --risk main --risk-threshold 10  # exit 3 if the files changed since main hold over 10% of the risk
gitmole . --sarif gitmole.sarif        # the findings for GitHub code scanning or GitLab
gitmole . --sbom sbom.cdx.json         # a CycloneDX SBOM of every package the lock files pin
gitmole . --compare last.json          # what changed since an earlier --json export
gitmole analysis-repo --no-run --hook  # a coding agent's edit hook: history's view of the files it just touched
gitmole . --since 2y --full            # the current team, every row and column
gitmole --clean                        # list what gitmole left behind, delete on a yes

A CI job that runs gitmole . --fail-on critical --markdown - >> "$GITHUB_STEP_SUMMARY" blocks on secrets in source files and still posts the report. The same scoring wires into Claude Code, Cursor, Gemini CLI and pre-commit as a hook that exits 2 over a threshold. Every option: docs/cli.md.

What you get

Reports on repositories you know, each at a pinned commit, published as gitmole wrote them:

Run times are one gitmole CLONE with every default step, on a MacBook Pro (M4, 16 GB).

Evolution

Every release is run from its own source over the same pinned repositories and scored by the same yardstick, so the graphs show what each release changed (measurement.md says how). On the three development repositories, revisions × lines of code (from 0.8.0) closed most of the gap between random and perfect, and later releases added findings rather than accuracy. On thirteen Apache repositories held out from tuning, the current release closes 61% of that gap and draws with churn alone, so the development numbers are the optimistic end.

The watch list is churn weighted by size. At the top it names about as many soon-to-be-fixed files as churn alone, and it orders the whole pool better, but per line read it finds fewer. A recency-weighted variant won on the development repositories and drew on the held-out ones, so it was not shipped (validation.md):

Every release's numbers, the other graphs and what they show: measurement-history.md.

The tool set

One tool per question; together they cover what a single command can tell you about a clone.

Why these and not others: docs/tools.md.

Docs

• Install: macOS, Linux, pipx, the check, pinned releases.
• Command line: every option, portfolio mode, exports and CI gates, big repositories.
• The report and the output files: what each section and each file means.
• Example reports: curl, django and react at pinned commits, regenerated by bin/render-examples.
• Validation: the watch list against other ways of ranking the same files at six cut-offs on three repositories.
• Measurement and its history: how a release is judged better, and every release judged.
• Why these tools: the rationale, what was left out, licences.
• References: the research and tools gitmole's rules are built on.
• Development: setup, tests, releases, code layout.
• Contributing: bugs, ideas, pull requests, security reports.

Safety

• Everything is offline except the optional clone step, which uses your existing gh auth. None of the tools send data anywhere; osv-scanner runs against a local copy of its database that you download once, and gitmole never downloads it for you.
• Remote targets are cloned into a fresh temp directory that is removed when the run ends. Local clones are only read. The secrets scan reads every branch; everything else describes the branch that is checked out. gitmole --clean lists every directory gitmole created and deletes them after a y/N question.
• Secret values never reach the output directory. betterleaks reports to gitmole in memory, and gitmole stores a short keyed hash in place of the value, the matched text and the commit message. The key is random, made for that one report and never saved.

License

MIT. gitmole runs the tools it wraps as separate processes and bundles none of them; their licences are listed in docs/tools.md.