The Problem

Hundreds of autonomous agents need to push and pull tiny changes in seconds, but classic Git services choke on full clones, merge queues, and client‑side history walks. The bottleneck is the need to materialize entire histories on the client while the server still verifies each commit.

What This Does

gitai implements a server‑centric model where the server answers all history queries and lands commits via compare‑and‑swap.

  • cmd/gitaly/main.go starts the gRPC server that exposes the API.
  • internal/objectservice/object_service.go serves single objects and sparse trees, allowing agents to fetch only the paths they need.
  • internal/userland/userland.go rebases a change onto the current tip and lands it atomically, while internal/changesetlog/log.go records every reference update in a dense, ordered log.
  • Conflict resolution is routed through internal/resolver/resolver.go, which can call any LLM provider or a deterministic tool via a vendor‑neutral protocol.

How It Is Wired

ENTRY POINT – cmd/gitaly/main.go

  1. main() parses flags and loads cmd/gitaly/config.toml.example.
  2. Calls internal/server.NewServer() to create a gRPC server.
  3. internal/server/server.go registers services: ObjectService, UserLandService, and ChangesetLogService.
  4. ObjectService delegates to internal/objectservice, which performs lookups in the object store (file system or S3).
  5. UserLandService calls internal/userland, which uses internal/db to fetch the current tip, rebase the change, and execute a compare‑and‑swap update.
  6. On success, internal/changesetlog records the operation; on conflict, internal/resolver handles resolution and retries.

WHAT THIS CODE TOUCHES OUTSIDE ITSELF –

  • SQLite/PostgreSQL for the write‑ahead log (internal/db).
  • Object storage (local file or S3) for packs (internal/objectservice).
  • gRPC network for client calls (internal/server).

WHAT EACH FILE IS RESPONSIBLE FOR –

  • cmd/gitaly/main.go – startup.
  • internal/server/server.go – service registration.
  • internal/objectservice/object_service.go – object retrieval.
  • internal/userland/userland.go – commit landing logic.
  • internal/changesetlog/log.go – change‑set logging.
  • internal/resolver/resolver.go – conflict resolution.

The call graph is linear from main to NewServer to Serve, with a single hop from services to data layers, keeping the blast radius limited to the server binary.

How To Use It

Setup – Build the binary:

# Clone
git clone https://github.com/moses-y/git-ai
cd git-ai

# Build the server
make build   # or go build ./cmd/gitaly

Configuration – Edit the sample config:

cp cmd/gitaly/config.toml.example cmd/gitaly/config.toml
# Adjust database DSN and storage paths

Running – Start the server:

./gitaly -config cmd/gitaly/config.toml

Agents connect via the gRPC endpoints or through the SSH shim (cmd/gitaly-ssh/main.go).

Real‑World Use

A CI pipeline spins up a gitaly container, agents use the gitai client to push changes, and a background graft-verify process runs tests on every new tip, automatically bisecting and reverting failures.

Code Health & Issues

  • Low – Secret‑shaped paths – client/testdata/gitaly_snioverride_cert.pem, client/testdata/gitaly_snioverride_key.pem, client/testdata/gitalycert.pem.
  • No other static issues – 1359 tests, MIT license, CI via .github/workflows/ci.yml.

The Bottom Line

gitai faithfully implements the Scion design for AI‑centric source control. It offers a clean, API‑driven server that scales with agents, but it requires a database and object store and a Go 1.20+ environment. It is suitable for teams running large numbers of short‑lived coding agents, not for casual Git hosting.