Provenance reported by the agent, not guessed later
Git AI addresses a problem that ordinary Git cannot represent. A commit records the human committer, but a modern change may combine work from several coding agents, prompts, models, and manual edits. Git AI adds a line-level attribution layer, so git ai blame can show an agent beside the lines it generated and git ai stats can summarize AI additions, accepted lines, human overrides, tools, models, tokens, and costs.
Its key design decision is correct: it does not inspect finished code and guess whether AI wrote it. Supported agents call git-ai checkpoint when they change files. On commit, the extension maps those checkpoints to lines and writes authorship metadata into Git Notes. Prompt text stays outside Git in a local SQLite database. That is more defensible than a classifier, and the published version 3 standard gives other tools a format to implement.
The result can answer useful review questions. A maintainer can trace a questionable line to the tool call and prompt that produced it. A team can compare generated lines with accepted lines rather than treating every suggestion as delivered value. Git AI also records sessions that produced no committed code, helping distinguish agent activity from durable output.
The personal install is easier than the internals
The macOS, Linux, and WSL path is a curl installer; Windows gets a PowerShell installer. Release assets cover x64 and ARM64, checksums are supported, and the project documents GitHub attestation verification. The installer puts the binary in a per-user directory, adds it to shell paths, and installs supported IDE or agent hooks. Running as root is discouraged because ownership can cause persistent daemon lock failures. Native Windows MSI and macOS PKG installers are still marked beta.
There is no per-repository setup and no Git hook or Git binary wrapper on the hot path. Git AI uses a background daemon and Git tracing, then reconciles attribution eventually. Developers continue to commit from the CLI, an IDE, or another Git client. The README says the daemon checks and updates agent hooks daily, and git ai install-hooks can refresh them manually.
That setup is pleasantly small for an individual. Organization-wide accuracy is not one command. Git Notes must travel with the repository, while server-side squash and rebase merges require the open CI actions or the team product. Multi-repository agent runs need each Bash command’s working directory inside the affected repository. Teams should verify aliases, worktrees, desktop clients, Graphite, and hosting merge policies before trusting aggregate numbers.
Privacy is good locally and different in cloud mode
Open-source mode requires no account and works offline. The privacy document says code, prompts, and agent usage data are not sent to Git AI when the user does not log in. Prompts remain on the laptop, while the repository’s Git Notes contain the agent, model, accepted-rate data, attributed lines, and the steering developer’s Git identity. Error and exception telemetry is enabled by default, but configuration can disable or redirect it.
The cloud and team products collect much more. A personal dashboard can upload tool use, MCP calls, skills, interruptions, errors, tokens, prompts, and responses. Team deployments can store employee identity, full prompts after best-effort secret and personal-data stripping, full sessions, and source-control metadata. Self-hosting keeps that data in the organization’s instance. Buyers need to evaluate these modes separately; the local CLI’s privacy properties do not automatically describe the hosted dashboard.
Git rewrites are the hard and valuable part
Basic attribution would be easy if commits never changed. Git AI attempts to carry notes through rebase, cherry-pick, stash, squash merges, resets, amend, branch switching, pulls, pushes, and worktrees. This is the feature that makes the project more than a commit-message convention. Formatters are supposed to preserve AI attribution rather than convert every reformatted line to human work.
The limitation table is refreshingly specific. File renames through git mv do not preserve attribution. Bulk rewrites with git filter-branch or git filter-repo, plus git replace, are unsupported. Server-side hosting operations need extra support. These are acceptable boundaries if teams know them, but they exclude common repository maintenance and migration jobs from any promise of an unbroken record.
More concerning are open correctness defects within supported-looking workflows. Issue 2067 demonstrates human text being attributed to Claude when no subsequent agent hook closes a checkpoint boundary. Issue 2103 reports three Graphite branch-movement patterns that strand uncommitted checkpoints, producing empty notes and human blame for AI lines across roughly 54 failing scenarios. For a provenance product, false authorship is the central failure mode, not a minor edge case.
Active development is fixing serious operational pain
The repository was pushed on August 12, 2026, and version 1.6.22 arrived two days earlier. Six stable versions from 1.6.17 through 1.6.22 shipped between July 29 and August 10, alongside preview builds. GitHub metadata listed 171 open issues and pull requests; separate search showed 61 issues and 108 pull requests. Nightly agent integration failures were filed on August 11 and 12, showing active compatibility monitoring as agent CLIs change.
That velocity is reassuring, but it also reflects a demanding system. An open report against 1.6.20 describes a Graphite rewrite path spawning Git work that consumed about 15 GB in one production case. Another says push-time notes reconciliation blocked Git pushes for minutes. Version 1.6.22 adds daemon memory-limit controls and a lighter note-rewrite mode, but its release notes do not claim that every reported rewrite or push path is resolved. Test the latest version rather than assuming a nearby fix covers the same mechanism.
Git AI is worth installing for developers who want to inspect their own agent use, and worth piloting for teams that need evidence about adoption and rework. The open standard and local-first architecture are strong foundations. The responsible rollout is to compare attribution with known test edits, exercise real rewrite and merge paths, set resource limits, and document privacy mode. When those checks pass, its data is far more useful than a vague “AI-assisted” commit trailer.