git-ai v0.2.0 发布：多 Agent 并发落地提速 7–9 倍

Official release notes (https://github.com/feder-cr/git-ai/releases/tag/v0.2.0) gitai 0.2.0 makes landing much faster and fixes correctness bugs found while doing it. ## Landing is 7 to 9 times faster Measured with `examples/graft/demo/acceptance-phase4.sh` on one machine (a 16-core laptop under WSL2): agents land 5 changes each on one branch, 20% of the changes conflict on purpose, seed 1. "Classic" is the same server with batching off: every agent rebases and retries its own compare-and-swap, up to 20 attempts. | 50 agents, 250 changes | classic | gitai 0.2.0 | |---|---|---| | changes landed | 100-101 | 200 | | attempts per landed change | 27 | 1.0 | | lands per minute | 240-272 | 1,862-2,544 | | p99 latency | 6.3-7.0 s | 1.5-1.8 s | At 100 agents gitai lands 392 of 500 changes at 1,422-1,686 per minute (classic: 115-121 at about 206 per minute). The changes gitai does not land are the planned conflicts, because these runs use no conflict resolver. With the deterministic resolver of `examples/graft/demo/resolve.toml` (`--mode land-resolve`), every conflict was resolved: 250 of 250 changes landed at 50 agents and 500 of 500 at 100. Ranges are two runs; see [BENCH.md](https://github.com/feder-cr/git-ai/blob/main/doc/graft/BENCH.md). What changed, root causes first ([PLAN8.md](https://github.com/feder-cr/git-ai/blob/main/doc/graft/PLAN8.md)): - Objects of a batch are written once and made durable once, as one pack, instead of being fsynced about three times each. - The landing decision comes from one range listing instead of nine git processes per change, and the single and batched land paths now share one implementation. - Every git command spawned a second `git rev-parse` just to choose `attr.tree`; the object format is now read from the repository config. ## Fixes - Landing decisions are exact when committer dates are skewed (clients setting old timestamps, agents with clocks behind). `git rev-list base..head` is not exact in that case; an already landed commit could be refused or merged again. The same exposure in the repository rebase todo list (`UserRebaseConfirmable`, `RebaseToRef`) is fixed too. A decision costs a fixed number of git processes, whatever the size of the history. - Writing objects into a repository no longer fails when housekeeping removes an empty object directory at the same moment ("finalizing object file: ... no such file or directory"). - `UserSquash` no longer reports success with an empty commit when the merge fails for a reason other than a conflict. ## Upgrading No configuration changes. `go install github.com/feder-cr/git-ai/...@v0.2.0` works with the module path of the project (v0.1.0 still carried the old path). ## Known limitations - In authoritative storage mode, concurrent writes to one repository queue on one reference lock (see [STORAGE.md](https://github.com/feder-cr/git-ai/blob/main/doc/graft/STORAGE.md)); a fairer queue is planned for 0.3.0, with garbage collection of packs and checkpoints. - The storage core still has no garbage collection of packs and no checkpoint compaction. - A lost batch attempt leaves one unreferenced pack until housekeeping prunes it. The full list is in [LIMITATIONS.md](https://github.com/feder-cr/git-ai/blob/main/doc/graft/LIMITATIONS.md). Repository README (current repository documentation, not release changes) Git designed for AI agents. Anthropic built **Scion**, a faster version control system for coding agents, and described it in [Redesigning source control](https://www.anthropic.com/engineering/redesigning-source-control): a server-centric system built for hundreds of agents that read, write and land code at the same time. Scion is internal to Anthropic and is not available to the public. So I built **gitai**: an open-source version of that design that anyone can run, and that the community can improve and maintain together. MIT licensed. Vendor neutral: the server never calls a language model, and every AI feature works with any provider, or none. gitai is an independent implementation of the publicly described design. It is not affiliated with or endorsed by Anthropic. --- ## Why Classic Git hosting was built for humans who clone a repository, work for hours and push once. Coding agents work differently: thousands of short-lived tasks, each touching a few files, each wanting to land in seconds, all on the same branches. Full clones, merge queues and client-side history walks become the bottleneck. Scion's answer is to move the work to the server: clients stay online and fetch only what they need, history questions are answered (and cached) by the server, changes land through a compare-and-swap instead of a queue, every update is an entry in a changeset log, and the repository state lives in a consistent database plus object storage so servers scale out. gitai implements these ideas, with normal Git repositories underneath. ## The Scion ideas, implemented | Scion idea | In gitai | |---|---| | **Always-online clients** that fetch exactly what they need | `ObjectService` serves single objects and sparse trees; `graft clone` and `graft sparse` materialize only the paths you ask for. | | **Source control as an API**: history runs on the server | Blame, path history, ancestry and code search run server-side and are memoized as derived data, computed once per commit. | | **Landing without a merge queue** | `UserLand` rebases a change onto the current tip and lands it with a compare-and-swap; concurrent lands on one branch are batched into a single reference update. | | **Automatic conflict resolution** | A conflicting land is resolved by a resolver you choose (any LLM provider, a deterministic tool, or none) through a versioned, vendor-neutral protocol. | | **Changeset log** | Every accepted reference update is recorded with its operation and actor in a dense, ordered log that clients list or watch live. | | **Storage core: a database and object storage, stateless servers** | Each change is a changeset in a write-ahead log in SQLite or PostgreSQL, with a compare-and-swap per reference; packs live in object storage (file, S3, GCS, Azure). Server nodes are caches that any node can rebuild, so you add nodes to scale. | | **Test after landing, revert the culprit** | `graft-verify` tests the tip, bisects a failure and reverts the change that broke it. | | **Monitoring agents ("superfans")** | Agents follow the changeset stream and report what matters to each component, also through Slack. | | **Agent-friendly review** | Reviews with semantic approval rules: a comment-only change can need fewer approvals than a logic change. | | **Agents as first-class users** | Per-agent tokens, an RPC allowlist and branch policies decide what each agent may do. | | **Strict cache tiers** | `graft-cache` caches immutable objects in daemon and regional tiers, verifying every object. | ## Architecture ``` agents, CI jobs, sparse workspaces graft CLI / Go SDK | v gRPC +-------------------------------------------------+ | graft-cache (optional daemon and cache tiers) | +------------------------+------------------------+ v +---------------------------------------------------------------+ | gitai server (any number of nodes) | | land - objects - changesets - derived data - search - review | | write path: changeset + compare-and-swap per reference | +-----------+--------------------------------+------------------+ | | v v +-----------------------+ +-----------------------------+ | SQLite / PostgreSQL | | object storage | | changeset WAL, refs, | | content-addressed packs | | changelog, reviews | | (file, S3, GCS, Azure) | +-----------------------+ +-----------------------------+ \ / local Git repositories = caches any node can rebuild ``` Details: [ARCHITECTURE.md](doc/graft/ARCHITECTURE.md) and [STORAGE.md](doc/graft/STORAGE.md). ## Quick start Requirements: Linux or macOS, Go 1.26, a C toolchain, Meson and Ninja (the build compiles a bundled Git). ```shell git clone https://github.com/feder-cr/git-ai.git cd git-ai make build # server, CLI and tools into _build/bin examples/graft/quickstart.sh # a server, a cache daemon, two agents and a land, in a temporary directory ./_build/bin/graft # the CLI and its commands ``` To run your own server, adapt [`examples/graft/config.toml`](examples/graft/config.toml) and start it with `_build/bin/gitaly serve config.toml`. To put the repository state in a database and object storage, add a `[graft.storage]` section: start in `shadow` mode, import your repositories, then switch to `authoritative` ([STORAGE.md](doc/graft/STORAGE.md)). Inside the code the extensions are called **Graft**: the `[graft]` configuration section, the `graft` CLI, `internal/graft` and `doc/graft`. ## Documentation - [Quickstart](doc/graft/QUICKSTART.md) and [configuration reference](doc/graft/CONFIGURATION.md) - [Architecture](doc/graft/ARCHITECTURE.md) and the [storage core](doc/graft/STORAGE.md) - [Landing and batching](doc/graft/LAND-BATCHING.md), [conflict resolution](doc/graft/RESOLVE.md), [derived data](doc/graft/DERIVED.md) - [Review](doc/graft/REVIEW.md), [search](doc/graft/SEARCH.md), [verification](doc/graft/VERIFY.md), [superfans](doc/graft/SUPERFAN.md) and [Slack chat](doc/graft/SUPERFAN-CHAT.md) - [Agent security](doc/graft/AGENT-SECURITY.md), [benchmarks](doc/graft/BENCH.md), [fuzzing](doc/graft/FUZZING.md) - [Limitations and roadmap](doc/graft/LIMITATIONS.md) - Design documents of each phase: [PLAN.md](doc/graft/PLAN.md) to [PLAN6.md](doc/graft/PLAN6.md), and [PLAN8.md](doc/graft/PLAN8.md) (faster landing) ## Benchmark 50 agents land 5 changes each on one branch; 20% of the changes conflict on purpose. "Classic" is the same server with batching off: every agent rebases and retries its own compare-and-swap, up to 20 attempts. Measured with [`acceptance-phase4.sh`](examples/graft/demo/acceptance-phase4.sh) on one 16-core machine, two runs: | 50 agents, 250 changes | classic | gitai | |---|---|---| | changes landed | 100-101 | 200 | | attempts per landed change | 27 | 1.0 | | lands per minute | 240-272 | 1,862-2,544 | | p99 latency | 6.3-7.0 s | 1.5-1.8 s | The 50 changes gitai does not land are the planned conflicts: these runs use no conflict resolver. With the deterministic resolver of [`resolve.toml`](examples/graft/demo/resolve.toml) every conflict is resolved and all 250 changes land. Details and more sizes in [BENCH.md](doc/graft/BENCH.md). ## Status Version 0.2.0. Everything above is implemented and covered by unit, end-to-end, multi-node, crash and fuzz tests. Interfaces may still change before 1.0. Known gaps (for example garbage collection of packs in the storage core) are listed in [LIMITATIONS.md](doc/graft/LIMITATIONS.md). ## Community gitai is meant to be maintained by its community. Open an issue to report a bug or propose an idea, start a discussion before a large design change, and send pull requests: tests and a short description of the reasoning make them easy to review. The design documents in `doc/graft/PLAN*.md` explain why things are the way they are. ## Credits and license gitai is MIT licensed, see [LICENSE](LICENSE). It started as a fork of [Gitaly](https://gitlab.com/gitlab-org/gitaly), GitLab's Git RPC server (MIT, Copyright GitLab Inc.), which provides the Git plumbing underneath; every upstream Gitaly RPC keeps working. The non-MIT `ee/` directory of upstream Gitaly is not part of this repository. Gitaly's own README is kept in [doc/UPSTREAM-GITALY.md](doc/upstream/README-GITALY.md), and third-party notices are in [NOTICE](NOTICE).