East River rewrites the storage under Git without asking anyone to migrate

Start with the push. A regular Git client opens the Git protocol against East River's service, and the negotiation looks like it would against any existing host ^[5]. A bridge inside the service translates those operations into a custom storage engine, and the server keeps no conventional Git repository as its source of truth ^[6].

At the edge, the manifesto commits to one contract, and it is a narrow one: the Git protocol ^[1]. GitHub, GitLab and other forges built large service layers around actual repositories ^[7], and in-house tooling tends to reach past that layer, into a server-side hook or a script that shells out to Git plumbing. The September post does not say which of that surface survives. East River says a GraphQL interface sits alongside the Git bridge ^[8]. New tooling can be written against GraphQL; a script that shells out to Git plumbing cannot call it at all.

There is less to the performance case than there is to the architecture. East River has described the system as supporting horizontal scalability, instant checkouts, large repositories and arbitrarily large files, and those remain company claims ^[9]. The May 4th product update covered the engine's planned capabilities, Git and Jujutsu compatibility, early-partner trials and planned code review ^[2]. A little over four months later ^[20], the September manifesto carries no production benchmarks and does not identify the early partners Brittain said in May were trialing the product ^[10]. For instant checkouts to matter to a specific team, that team's slow path has to be checkout and object transfer under concurrent readers. If the bottleneck is the test pipeline instead, sharding the object store changes nothing for them.

East River started in 2025 on the thesis that coding agents would push source-control workloads past the assumptions embedded in Git and conventional Git hosting ^[3], and the company argues the repository-based architecture behind most Git hosting will become the constraint ^[11]. Half of that is observable now: according to runtimewire, agent workloads run concurrently in isolated cloud environments, repeatedly pulling repository context and pushing work back for review, and operational patterns once associated with the largest monorepos are appearing inside smaller engineering organizations ^[12]. The other half is a claim about where the ceiling sits, and the September post does not measure it.

Jujutsu opens the second route in. Martin von Zweigbergk created it, and it can use Git as a backend today, so one engineer can adopt its change model while colleagues keep their Git clients ^[13][14]. He joined East River as chief technology officer on September 1st after 15 years at Google ^[15], ten days before the manifesto went out ^[16]. Before Jujutsu he worked on Fig, a Mercurial client used with Google's Piper monorepo, and he contributed to Git ^[17].

The adoption path, at least, is already finished engineering. Developers keep using Git, CI keeps speaking Git, and client migration stays a separate choice for each person or organization ^[18]. The engine meant to justify all of that was expected to enter private beta later in September, on East River's own September 1st statement ^[19].