Skip to main content

The audit layer for AI-generated commits. Independent, cross-family verification of what your diff actually did.

Project description

git-to-doc

The audit layer for AI-generated commits.

PyPI Python License: MIT

🏆 Built at the GDG Cloud Boston × Northeastern University hackathon (Powered by Gemma), where it won 1st place. Full write-up: shivanshsingh.in/git-to-doc.

The problem

A lot of commits are written by AI now, and so are their commit messages. The trouble is that the message often doesn't match what the diff actually did. It skips a side effect, softens a behavior change, or describes the intent instead of the result. Reviewers skim the message and trust it. That gap is where bugs slip through.

git-to-doc closes the gap. Point it at a commit and it tells you where the message and the diff disagree, with every finding pinned to a specific file and line.

What it looks like

$ git-to-doc verify HEAD

  🔍 Verifying commit a1b2c3d
     Auditors: qwen2.5-coder:14b, deepseek-coder-v2:latest (2 independent, cross-family)

  ORIGINAL MESSAGE
  fix(auth): tidy up the login helper

  ⚠️  1 DIVERGENCE (all auditors agree)
   • login() now issues a session token instead of returning a boolean, and also
     writes an audit-log entry that the message never mentions
     app/auth.py:42

  📊 Benchmark: 69% precision, 36% recall (synthetic n=168, 16GB tier, see BENCHMARKS.md)

When the message honestly covers the diff, you get a green "matches" line instead. When only one of the two models flags something, it shows up as possible and asks you to verify it, rather than being stated as fact.

How it works

How git-to-doc verify works

  1. Two models, different families. By default qwen2.5-coder and deepseek-coder-v2. Different training gives them different blind spots, which is exactly why agreement between them carries weight.
  2. They read the diff blind. Each model describes what the change does before it ever sees the author's message, so a misleading message can't steer it.
  3. Then they compare. Each independent reading is checked against the commit message. Anything the message omits or misstates becomes a divergence, and every divergence has to cite a file and line or it gets thrown out.
  4. Agreement sets the confidence. If both models flag the same spot, it is HIGH. If only one does, it is possible. If the models can't produce a valid, cited report at all, the tool errors out instead of inventing a reassuring "all clear."

Install

pip install git-to-doc

# pull the default two-model panel
ollama pull qwen2.5-coder:14b && ollama pull deepseek-coder-v2:latest

git-to-doc runs against a local ollama daemon by default, or ollama.com if you set OLLAMA_API_KEY.

Those two models are only the default. Anything you can ollama pull works (Gemma included); pick a different pair for a single run with --auditors model-a,model-b. Not sure what your machine can handle? Run git-to-doc doctor and it reports your RAM, recommends a pair (it knows 8, 16, and 32 GB tiers), and lists anything still to pull.

Usage

git-to-doc verify HEAD                    # audit the latest commit
git-to-doc verify a1b2c3d                 # audit a specific commit
git-to-doc verify --url <github-pr-url>   # audit a pull request instead
git-to-doc verify HEAD --json             # machine-readable output
git-to-doc verify HEAD --auditors m1,m2   # pick your own model panel

Benchmarks

Measured on the default 16 GB model pair, not estimated:

  • Synthetic (n=168, known ground truth): 69% precision, 36% recall.
  • Real-world (n=95 actual AI commits): 29% of commits carried a high-confidence divergence, and the two models agreed on 11% of all findings.

Two things worth saying plainly. Recall is on the low side because HIGH only fires when both models independently agree, which is a strict bar by design. And that 11% agreement on real commits means most findings are single-model possible flags, not certainties. The full method, per-tool breakdown (Copilot, Claude, Cursor, Devin, Jules), and the caveats live in BENCHMARKS.md.

Also useful

git-to-doc started life as a commit-documentation generator, and those commands are still here:

  • git-to-doc <diff | pr-url | folder> turns a diff into a Conventional Commit message, a changelog entry, and a plain-English summary.
  • git-to-doc pull-request writes a PR title and body from your branch, then audits that AI-written description against the diff before you post it (--skip-audit opts out).
  • git-to-doc install-hook installs a prepare-commit-msg hook that drafts the message from your staged diff.

License

MIT, © 2026 Shivansh Singh

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

git_to_doc-0.4.0.tar.gz (33.8 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

git_to_doc-0.4.0-py3-none-any.whl (30.0 kB view details)

Uploaded Python 3

File details

Details for the file git_to_doc-0.4.0.tar.gz.

File metadata

  • Download URL: git_to_doc-0.4.0.tar.gz
  • Upload date:
  • Size: 33.8 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.2.0 CPython/3.9.6

File hashes

Hashes for git_to_doc-0.4.0.tar.gz
Algorithm Hash digest
SHA256 ed57d10d88395b925c20345b437b4211b54683b1eb21abf35cd8fe7dddc2da61
MD5 bce963c7f65118205bdf096794edba1f
BLAKE2b-256 c7edf881dd0039b7804675f4dbb59f106c808fed1873e5f1df7f6d721f9cfc81

See more details on using hashes here.

File details

Details for the file git_to_doc-0.4.0-py3-none-any.whl.

File metadata

  • Download URL: git_to_doc-0.4.0-py3-none-any.whl
  • Upload date:
  • Size: 30.0 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.2.0 CPython/3.9.6

File hashes

Hashes for git_to_doc-0.4.0-py3-none-any.whl
Algorithm Hash digest
SHA256 83d24c26f669f77e34956bdb778cbb65920cb9eb32595ed3f0cac986a2e74e47
MD5 1693b2cec810a738c02776a99ebbed9a
BLAKE2b-256 89d9f4bba5ed7de4c327cbf8f904134ab859060ffa8ac049b48655f3617fc68d

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page