How Git AI Works

Demo Video

Most attempts to quantify and track AI code authorship focus on counting lines of code at the moment of insertion. That approach tends to overcount AI code because it doesn't track code through the entire development lifecycle. What if a developer undoes the AI change? Copies an AI function to a new part of the repo? Performs a rebase? Cherry-picks the code many commits later on a different branch? Accurate measurement requires following code from the development machine through to merge.

Git AI approaches the problem differently: by building an accurate git blame for tracking AI code, accurate stats follow naturally. Git AI preserves AI code attribution as it moves from local development environments, through a PR, through code review, and onto the main branch.

Design choices

• Avoid tying to a single vendor—the ecosystem is multi-agent. Agents are the new IDEs (developers get to choose).
• Track the AI code that lands. No fuzzy stats like generated/accepted lines.
• No filewatchers or keyloggers (critical for enterprise use).
• No long-running daemons or background processes.
• No heuristics to identify AI code. Coding agents explicitly mark inserted hunks as AI-generated.

Part 1: What happens on a developer's machine?

Like git, most of the work happens offline on the developer's machine.

Checkpoints and Agent Hooks

Git AI checkpoints track incremental code changes between the start and end of a commit. Each checkpoint contains a diff between the current state and the previous checkpoint, marked as either AI or human authored. These checkpoints are temporary and are stored in .git/ai until the commit is made.

Coding agents like Cursor, Claude Code, and GitHub Copilot mark their changes as AI authored by invoking Git AI when they make changes. Any agent supporting hooks can work with Git AI. Here's an example of hooks Git AI sets up for Claude Code in ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "hooks": [
          {
            "command": "git-ai checkpoint 2>/dev/null || true",
            "type": "command"
          }
        ],
        "matcher": "Write|Edit|MultiEdit"
      }
    ],
    "PostToolUse": [
      {
        "hooks": [
          {
            "command": "git-ai checkpoint claude --hook-input \"$(cat)\" 2>/dev/null || true",
            "type": "command"
          }
        ],
        "matcher": "Write|Edit|MultiEdit"
      }
    ],
  }
}

Git AI requires two hooks: one before and one after the agent edits code. The pre-edit checkpoint ensures any human changes since the last agent edit are marked as human authored. The post-edit checkpoint picks up newly inserted AI code and marks it as AI authored.

When code is committed, Git AI condenses all checkpoints into an Authorship Log optimized for fast lookups:

/path/to/file.ts
  promptA: 2-24 31-32
  promptB: 25-30
/path/to/other/file.ts
  promptA: 1-212    

Known Limitations

Attribution is not properly preserved in these cases, though work is underway to close these gaps. See known limitations for the full list:

• Copy/pasting AI code doesn't transfer attribution to the new file/location
• git mv doesn't move attribution
• Code formatting tools may change AI code attribution to human
• Undo/redo operations may not properly preserve attribution

Note: There is an active project to transition from line-based diffs to operational transforms for better accuracy tracking moving AI code, changes from a formatter, and preserving AI attribution through complex refactors and edits.

Authorship Notes

Authorship Logs are addressed by commit SHA and should be treated as immutable. On post-commit, each Authorship Log is attached to the new commit using a git note.

git log --show-notes=ai

commit 02e97d75fde395576205d18dacf0e51627f356d5 (origin/feat/narrow-git-status-on-checkpoint)
Author: Sasha Varlamov <sasha@sashavarlamov.com>
Date:   Tue Oct 14 18:37:34 2025 -0400

    Filter edited paths/will edit paths to ensure that they are part of the repo

Notes (ai):
    src/commands/checkpoint.rs
      6e4d6f2 51-52,54,58-110,901-931,934-947
    src/git/test_utils/mod.rs
      6e4d6f2 4,410-425

Blame and Stats

git blame tracks which commit inserted or last modified each line of code. Since Git AI notes are indexed by commit SHA, AI authorship information can be quickly overlaid on top of git blame.

For line 2 of file.ts inserted by commit 6e4d6f2, Git AI looks up the Authorship Log for that commit to determine if the line was written by an AI prompt. Even if lines have shifted in intervening commits, git blame --line-porcelain <file> provides the original line position for correct lookups and overlay.

Part 2: Distribution

Early versions of Git AI required developers to manually add git hooks and refspecs for syncing notes to every repository. This was cumbersome, especially in repos with existing hooks. Teams requested a one-liner setup that worked across all repos and agents.

The solution: making Git AI a git wrapper. This allows Git AI to act as if it has pre- and post-command hooks on every git command without explicit hook configuration in each repository.

We've profiled the wrapper and found the overhead to be about 10-20ms per command -- most of it in spawning the git process. See the wrapper implementation:

let repository = repository_option.as_mut().unwrap();

run_pre_command_hooks(&mut command_hooks_context, &parsed_args, repository);

let exit_status = proxy_to_git(&parsed_args.to_invocation_vec(), false);

run_post_command_hooks(
    &mut command_hooks_context,
    &parsed_args,
    exit_status,
    repository,
);

let post_command_duration = end_post_command_clock();

exit_status

Install

Git AI installs with a single command:

curl -sSL https://raw.githubusercontent.com/acunniffe/git-ai/main/install.sh | bash

The install script:

• Downloads the correct binary for the platform
• Creates symlinks to route git calls to git-ai
• Installs hooks for the IDE/agent

Advanced configuration and installation options for enterprises are also available.

Syncing Notes

Authorship Log notes are synced to the remote repository after successful pushes or fetches, ensuring all contributors have copies of Authorship Logs for cloned commits.

Performance:

Git note merges are fast, even on large repos. Sync times scale linearly with new notes:

============================================================
SUMMARY
============================================================
Total Notes     New Notes    Sync (s)   
------------------------------------------------------------
1,000           10           0.007       
1,000           100          0.007       
1,000           500          0.008       
1,000           1000         0.010 
------------------------------------------------------------
10,000          10           0.007       
10,000          100          0.008       
10,000          500          0.008       
10,000          1000         0.010 
------------------------------------------------------------
50,000          10           0.008       
50,000          100          0.008       
50,000          500          0.008       
50,000          1000         0.010
------------------------------------------------------------
100,000          10          0.009
100,000          100         0.009
100,000          500         0.009
100,000          1000        0.011

Git hosting platform support:

• GitHub: Notes can be pushed but aren't displayed in the web UI
• GitLab: Native support for Git notes with web UI visibility
• Bitbucket: Limited support; notes can be pushed but aren't displayed in the web UI

Part 3: History Rewriting Operations

Since AI authorship is indexed by commit SHA, rewriting operations that create new commits leave new commits without authorship logs. However, as long as Git AI knows the repo state before and after the operation, it can reconstruct accurate authorship logs for the new commits.

The system handles rewrite operations as follows:

• Rebase (1:1 mapping): Authorship logs are copied from original to rebased commits. If trees differ, logs are reconstructed by replaying commits in the new context.
• Squash/Merge (many-to-one): Multiple commit Authorship logs are merged—AI code from any squashed commit is preserved in the final commit's log.
• Cherry-pick (1:1 mapping): Similar to rebase—authorship from the source commit is transferred to the new commit.
• Reset: When resetting backward, working logs are reconstructed to preserve recent authorship state. Forward resets preserve existing authorship.

Web UI Squash & Merge / Rebase & Merge

Most Git hosting platforms don't have first-class Git AI support, so squash or rebase operations in web UIs don't update Authorship Logs the way local operations do. However, all needed information is available in SCM webhooks: original commit SHAs, new commit SHAs, and branch name.

The Git AI SCM Bot (in active development) listens for webhooks and automatically reconstructs Authorship Logs for these commits. For early access to a cloud or self-hosted version, schedule a call.