gitai 0.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.

What changed, root causes first (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); 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.