// HACKER NEWS — CYBERSECURITY
What Comes After Git
East River Source Control has been around for over a year now, but we haven’t
been talking much publicly about what we’ve been working on. We aren’t
announcing anything just yet, and we will soon, but we wanted to share some of
our thinking around version control and where things are going.
Building software is fundamentally a collaborative task. Projects start with humble
beginnings, and end up growing into incredibly large and complex systems. But what cargo new generates is the same thing as what a multi-billion line monorepo
contains: source code. Storing this code safely and securely, managing how it
changes over time, and ensuring its availability to developers are some of the
most critical functions of any technology organization.
In the old days, you might have had a shared server where your code lived.
Academia and then industry developed what are now called Source Control
Management (SCM) and Version Control Systems (VCS). And even within the VCS
space, we have seen many, many tools over the years: CVS, SVN, and Git are the
tools that have dominated the open source space, but there have been others as
well: Perforce, ClearCase, Fossil, Mercurial, SCSS, Monotone,
BitKeeper, and many more. These tools became the standard way to store your code
and have your team collaborate on changes to it.
The rise of agentic development has changed many things about how we develop
software, but it places particular strain on your version control system. Teams
are producing more code more quickly than ever before, ballooning repository
sizes, increasing the number of active branches, and producing significant
contention on merging in new work. Agents work well with monorepos, because
they can get more access to more context more easily, exacerbating these issues
as well. They’re moving development environments to the cloud, with isolated
environments, which means that they need fast clone times. All of these problems
used to be the domain of larger organizations, but agents are bringing big company
problems to the rest of us.
We believe that as organizations continue to scale up their ambitions, they will
need a next generation VCS tool. But they are rightfully a bit conservative with
adopting new tooling in this space. As I said above, source code is one of the
most precious commodities an organization has, and change has risks as well as
rewards. We deeply appreciate these concerns, and so are building a bridge from
the present to the future.
Lots of Git servers exist though. What makes us special?
At a high level, the way most places that host Git repositories for you looks
something like this:
Your git client connects to their service via the Git protocol. Inside the
service, they store your repositories on disk, and have a service layer
that connects the two.
Now, this is a bit reductive: it is going to be many servers, with a complex
layer of services in front of the repositories. The storage will be replicated,
and there’s all sorts of stuff going on. We’re focusing on the overall
architecture here, but don’t mistake the simplicity of the diagram for the
simplicity of the system. There is a lot going on here, but those details
aren’t germane at this exact moment.
In that spirit, here is the diagram for what we’re doing: