A new model for source control by Alcides Fonseca

A new model for source control

Years before Github (or git, for that matter) existed, I was publishing my open source software on my own websites. However, larger projects (and eventually some of mine) used a website called SourceForge, which was a reliable source — you could trust downloads from that website. At some point, SourceForge offered CVS and/or Subversion support — for the youngsters, CSV and Subversion were other version control systems that predate git.

Around 2007, Github launches and popularized Git and having a web-interface to manage your code and, more importantly, Pull Requests. Pull requests lowered the barrier to contributing to open-source projects for the first time. Traditionally, you would have to send a patch, or request write access to the repo. With GitHub, you can create a copy, work on your copy and use the web interface to request the maintainer to accept your change, with a nice-enough interface to do it without having to open the terminal or IDE.

I am very surprised that this model worked for almost 20 years without breaking. Of course many companies use several alternative workflows, but I would say this model is very, very popular with all the companies that I have worked with using it.

Until now. Github has reported an increase in downtime, which can be linked to the increase in agent activity that increases the load of their servers. This increased load may change the economically viability go Github (especially for open-source projects) and for Microsoft as a whole (as other LLM-training companies also benefit from their hosting and available code).

In parallel, Anthropic has made work-trees the default mode for working on multiple topics in parallel on your machine. I mostly disagree with this choice because the savings in disk space are not worthwhile, compared with the isolation you get by having different checkouts in your machine. Additionally, I think the use we have made of git (which I believe to be fantastic for their initial purpose!) has shown some limitations.

The first limitation is that you always need to have the full (linear) history of your project since the beginning of time. I love to be able to blame a file and show me that 30 years ago someone changed it. But for slow-paced, mostly stable open-source software that’s fine. But for many large companies, that is an undesirable overhead if you want your agents to quickly checkout a new copy of the repo to explore a thing or two. This is where worktrees have an advantage, at the cost of losing the isolation of checkouts. What if one of your agents deletes the .git folder? I want more isolation, even being able to move the isolation unit between machines. Cloudflare has released their OS and Browser as foundation pieces of their isolation infrastructure for agents. The code forge needs a similar approach.

The second limitation is that commits all have the same granularity. Consider that you develop a new feature in a branch, doing 10 commits. When merging or rebasing, you have the option to either move all 10 commits, or squash them into one big commit (or something in between). Personally, I love to keep them separate, so I can undo them later. But then you lose the information of what branch it came from (and nowadays, you really should garbage collect your branches!) when understanding the reason of why some change occurred, or if you want to remove the full feature. I see a lot of companies requiring a super-commit that encompasses smaller commits inside. And through git notes (metadata that is attached to commits), you could implement an UI that supports this feature, as long as everyone in the team uses your custom git wrapper.

Despite these two limitations, git already provides the solution for agents: git is distributed and you can have a master repo for your company, one semi-master repo for your team, one repo for yourself, and many different repos for each of your agents. You can push changes from any repo to another, you do not have to go through the centralized Github/Gitlab/Gitea instance!

Of course, skipping the centralized server makes you lose CI/CD (well, not necessarily, but in practice) and a centralized view of issues and pull-requests. So what we really need is a distributed, hosted installation of gitlab (or similar) that can have the granularity that your organization requires. You merge PRs by your agents into your repo, and only then do those PRs get created on your team. But if you want to cooperate on the same PR, you can push directly to your team member. But you want the work on a single PR to be isolated (this is what I believe is failing in the current agent/sourceforge model).

While not necessarily better for open-source projects, which have the open kimono policy that I love, this model fits better in the complex organizational behavior of larger companies, and the high influx of code that is happening today,...