git-ai: tracking AI-generated code with Git Notes and an AI blame command
A Git extension for tracking the AI-generated code in your repos
At a glance
- What is it?
- git-ai is a Rust Git extension that records which agent, model and prompt produced each line of AI code. It installs as a single shell script, stores attribution outside the repository, and adds a git ai blame and git ai stats command.
- Who is it for?
- Adopt git-ai if your team already commits AI-assisted code and you need line-level attribution that survives review, or if you want per-model acceptance numbers from git ai stats --json. Do not adopt it if you need attribution to work in a CI system the project has not documented, or if your policy forbids storing prompt sessions outside the repository.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap git-ai fills: commits do not record which model wrote the code
Git records who committed a change, not what produced it. Once an agent writes a function and a human commits it, the commit author field says the human's name. The information that mattered, which agent, which model, which prompt, is gone unless someone wrote it in the message.
git-ai targets that gap. The README describes it as "an open source git extension that tracks the AI-generated code in your repositories", and states that after installing, "every line of AI code is linked to the agent, model, and prompts that generated it". The intended audience is teams already committing agent output at volume and asking two questions: how much of this repository is AI-written, and where did a given line come from. The README frames the payoff as not losing "the intent, requirements, and architecture decisions behind your code".
This is a provenance tool, not a code review tool. It does not tell you whether AI code is correct. It tells you which lines are AI code and what generated them, which is the input the other questions need.
How attribution is stored: Git Notes, a redaction pass, and no hooks
The README's "Our Choices" section states that git-ai does not rely on Git Hooks and does not wrap the Git binary. That is the central design decision. Hook-based approaches run on every commit in every repository where they are installed, and they have to be set up per repo. git-ai instead attaches attribution metadata at commit time from the extension itself, which is why the README can say "no per-repo setup or git hooks required" and that commit works with the agent, git, or any Git client.
Storage splits in two. Commit-level attribution travels with the repository through Git Notes, and the README points to a versioned specification, git_ai_standard_v3.0.0.md, as the open standard for tracking AI-generated code with Git Notes. Prompt sessions are handled differently: the README says sessions are "scanned and redacted, and saved outside of Git", with the stated reasons being lean repositories, fine-grained access control, and preventing PII or secrets from leaking. The repository root also contains a data-privacy.md file, which is the document to read before deciding where that boundary sits in your environment.
The dependency list in Cargo.toml is consistent with this picture. rusqlite with the bundled feature and gix-config, gix-index and imara-diff appear as dependencies, so line-level diffing and a local SQLite store are part of the implementation. The repository also ships a spec directory and an agent-support directory, which is where per-agent integration lives.
Installing git-ai and running a first AI blame
The README gives one install command for Mac, Linux and Windows WSL, and a separate PowerShell command for Windows. The install script is fetched and piped to a shell, so read install.sh in the repository first if your environment requires that.
curl -sSL https://usegitai.com/install.sh | bashOn Windows the README uses this instead:
powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://usegitai.com/install.ps1 | iex"After installing, work as usual. The README's promise is that you prompt and commit with no workflow change, and the commit output gains an attribution bar:
git commitThe README shows that output ending in a split between "you" and "ai", with a percentage on each side, in the example 6% human and 94% AI. The first command worth running on an existing repository is blame, which the README describes as a drop-in replacement for git blame supporting all standard git blame flags:
git ai blame /src/log_fmt/authorship_log.rsIn the README's example output, lines attributed to an agent show the agent name where a human name would normally appear, so the same file shows both a person and "claude" against different lines. For aggregate numbers, the stats command emits JSON:
git ai stats --jsonThe README's example JSON contains human_additions, ai_additions, ai_accepted, git_diff_deleted_lines, git_diff_added_lines, and a tool_model_breakdown keyed by strings such as claude_code/claude-sonnet-4-5-20250929. A range form is also documented:
git ai stats <start_sha>..<end_sha> --jsonWhere git-ai gets in the way
The design depends on the agent integration knowing about the session. The README lists supported agents, including Claude Code, Codex, Cursor, GitHub Copilot, OpenCode, Pi, Windsurf, Droid, Amp, Gemini, Continue, Junie, Rovo Dev and Firebender, and links to a page for adding your own. An agent outside that set produces no attribution until someone writes the integration, and the README does not claim otherwise.
Prompt sessions live outside Git. That is a deliberate trade-off: repositories stay small and access can be scoped, but the prompt history is not part of the clone. Anyone who checks out the repository without access to that external store sees commit-level attribution and not the prompts. If your review process assumes a single artifact contains everything, this split will surprise you.
The README states that CI actions preserve attribution through rebase and both merge strategies, but it does not document rollback, and it does not describe what happens to attribution when patches move between repositories by email or archive. Treat those as unverified paths and test them on a scratch clone before depending on them.
The install path is a pipe-to-shell script from a website, with a PowerShell equivalent. That is normal for developer tooling and still a supply-chain decision your team has to make explicitly. The repository also ships install.sh and install.ps1 at the root, so pinning to a reviewed copy is possible.
Finally, blame output is only as good as the redaction pass. The README says sessions are scanned and redacted before storage, but it does not describe the redaction rules in the README itself; data-privacy.md is the file to check.
git-ai compared with the standard git blame workflow
Plain git blame answers one question: which commit last touched this line, and who authored that commit. git-ai keeps that view and adds a second axis. In the README's example, one file shows both a human author on some lines and "claude" on others, which is information git blame cannot express because the commit author is the same person either way.
The difference in approach matters more than the feature list. A team using plain git blame can approximate AI attribution with commit message conventions, for example a trailer naming the agent. That costs nothing to install and survives every clone, but it is commit-level, it depends on discipline, and it cannot tell you which lines inside a mixed commit came from the model. git-ai operates at line level and records the model, which is what makes the ai_accepted number in git ai stats --json meaningful: the README describes it as AI lines generated versus committed, with accepted rates and human overrides broken down by tool and model.
The cost of that precision is a dependency on the extension being present when the code is written. A trailer convention degrades gracefully; a missing integration produces nothing to attribute.
Maintenance, licensing and upgrade cost
The repository is not archived, and the last push was on 2026-09-15. Releases are frequent: v1.7.5 on 2026-09-09, v1.7.4 and v1.7.3 on 2026-09-08. Cargo.toml lists version 1.7.6, one patch ahead of the newest published release in this record, which is worth knowing if you build from source rather than using the install script.
The project is written in Rust with edition 2024, so building from source requires a recent toolchain. A Cargo.lock, a flake.nix and a Taskfile.yml are present, so both Nix and Task-based build paths exist, and the repository ships README-nix.md. The dependency list is long, including rusqlite with bundled SQLite and vendored OpenSSL on Linux, which makes source builds heavier than the single-script install.
Licensing is Apache-2.0. That is a permissive licence with an explicit patent grant and a requirement to preserve notices. It does not settle the question that matters most here: where prompt sessions are stored, who can read them, and whether that store is inside your compliance boundary. The README says sessions are saved outside Git and redacted, and data-privacy.md exists in the repository, but the README does not spell out the retention or access model. Read that file and the configuration documentation before enabling this on repositories that contain anything regulated. Nothing here is legal advice.
Editorial conclusion
Adopt git-ai if your team already commits AI-assisted code and you need line-level attribution that survives review, or if you want per-model acceptance numbers from git ai stats --json. Do not adopt it if you need attribution to work in a CI system the project has not documented, or if your policy forbids storing prompt sessions outside the repository. Before rolling it out, verify on a throwaway clone that git ai blame reports the expected agent names for your toolchain, and read data-privacy.md and the configuration docs to confirm where sessions are written and how redaction is applied.
Frequently asked questions
How does git-ai work?
It attaches attribution metadata to commits at commit time rather than through Git Hooks, using Git Notes for commit-level data. Prompt sessions are scanned, redacted and saved outside Git, and blame and stats read that attribution back per line.
How do I install git-ai?
On Mac, Linux and Windows WSL the README gives a single command that pipes install.sh to bash. On Windows it gives a PowerShell command that fetches and runs install.ps1. No per-repo setup or Git hooks are required.
What is git-ai?
It is an open source Git extension, written in Rust under Apache-2.0, that tracks AI-generated code in a repository. The README says it links every line of AI code to the agent, model and prompts that generated it.
How do I use git-ai after installing it?
Commit as you normally would with your agent or Git client, and attribution is linked automatically. Then run git ai blame on a file to see per-line attribution, or git ai stats --json for aggregate AI percentages and a tool and model breakdown.
Is git-ai free?
The repository is licensed Apache-2.0 and the README describes the tool as open source and local-first, working offline with no login required. The README does not document a paid tier or any pricing.
What can I use instead of git-ai for AI attribution?
The nearest low-cost alternative is a commit message convention that names the agent, which needs no installation and survives every clone. It is commit-level rather than line-level, so it cannot tell you which lines in a mixed commit came from the model.
Community notes