feder-cr/git-ai

If you are coordinating a handful of coding agents that each touch a few files and then push, gitai is worth watching, but it is not a drop-in git replacement yet: it is a young, pre-1.0 server with heavy build requirements.

The problem

A coding agent typically finishes a small task in seconds and wants to land it immediately, but classic git hosting assumes a human who clones, works, and pushes once. When dozens of agents land on the same branch, full clones and merge queues become the bottleneck, and each agent must rebase and retry its own compare-and-swap against a moving tip. gitai changes that step: the server rebases incoming changes onto the current tip and lands them with a compare-and-swap, batching concurrent lands on the same branch into one reference update. The intended result is that more agent changes land, with fewer retries, without a central merge queue.

What's different

The design follows Anthropic's described Scion system, which the README says is internal and not public; gitai is an independent MIT-licensed implementation of that publicly described design, not affiliated with Anthropic. The server answers history questions such as blame, path history, ancestry, and code search and memoizes them as derived data per commit. Clients stay online and fetch only the objects they need, so the graft CLI can materialize sparse paths instead of full clones. AI conflict resolution is provider-neutral, and the README states the server never calls a language model.

The trade-off is architectural: this is a server-centric system, not ordinary git with an extension. Adopting it means running a gitai server and possibly a cache daemon, and the interfaces may still change before 1.0. The author's benchmark claims a large landing improvement, but it comes from one 16-core machine with two runs, and the same page acknowledges the conflict resolver was off in that comparison, so treat the numbers as author-reported rather than a general guarantee.

Who should try it

This fits teams already running many parallel coding agents against shared branches and willing to operate their own version-control service. It could also suit developers curious about the Scion design who want a runnable implementation to study or contribute to, since the design documents and project instructions are provided.

It is a poor fit if you only need a normal git host for a human team, or if you expect a finished, stable product; the README marks version 0.4.0 with possible interface changes. If you are not ready to run a server, there is no documented lightweight path: setup requires building the server and CLI, and running your own instance means adapting a config file.

Requirements and limitations

Building from source requires Linux or macOS, Go 1.26, a C toolchain, Meson, and Ninja, because the build compiles a bundled Git. That dependency chain makes the initial setup heavier than a typical Go binary. Ongoing operation adds a server, optional cache tiers, and a configuration file.

The project starts as a fork of Gitaly, so upstream Gitaly RPCs keep working, but the non-MIT ee/ directory is excluded. Storage can move to a database and object storage through a shadow then authoritative sequence described in the storage docs. Known gaps, including garbage collection of packs, are listed in LIMITATIONS.md, and those should be reviewed before depending on it for long-lived repositories.

HotRepo's take

gitai appeared on the NEW-REPOSITORY board at #3 with 990 total stars on 2026-10-25, two days after HotRepo started tracking it. That snapshot shows attention but cannot establish persistence, so the trend evidence is insufficient to judge durability. Before experimenting, read LIMITATIONS.md and the storage guide to confirm the storage path and known gaps fit your repository needs.