What Comes After Git

Git was born from the collaboration problems in the Linux kernel. Nearly a decade later, new problems arose when Kubernetes (the operating system of the cloud) brought open-source collaboration to a new level.

I saw the pain points of git (and GitHub) firsthand working on Kubernetes open-source. Will a new version control system (or something that solves similar problems) spring up?

Some ideas on what a new version control system would look like.

• Atomicity across projects –  GitHub is a de facto monorepo and is used as such. Splitting code with dependencies can result in complex syncing and CI pipelines. Submodules aren't an adequate solution.

• Native package management – Packages are tightly coupled with code (see GitHub's Missing Package Manager). Git's content-addressable storage tells us that we are using the right set of files for a revision. We should also have the same guarantee when consuming source code through package managers. Better yet, maybe we can build generic primitives toward a universal package manager.

• Semantic diff – Can we figure out how to use version control to have more context-aware merges? Can you believe that we still rely on a text diffing algorithm from 1976 (and its shortcomings)? Git still has trouble with file renaming. GitHub Copilot, but for merge conflicts? Semantic diff has been tried before, but language-specific implementations will likely never work.

• Merge Queue Data Structure – Two pull requests simultaneously pass all tests but fail when merged together. While more of a workflow feature rather than a version control one, it's core enough to the idea of tracking history (i.e., building the commit graph) that a strong case could be made for making it a first-class citizen.

• Fan-out pull requests – The idea that library owners could write a patch for their software and distribute it to all downstream users. While downstream users wouldn't be obligated to update, it could take a lot of the work out of N different consumers figuring out how to upgrade. Think dependabot, but with all types of updates (minor, security, and breaking). Most useful inside companies, but an analog might make sense in open source.

• Terrible UX of Git – overloaded and inconsistent commands, and more. I believe that the underlying problem is the divergence of the workflow from the tool. Either git should be fully decoupled from the pull request and merge workflow or integrated into what's now become "git flow".

• Large file storage – there are extensions like git lfs that provide some support for larger files but aren't great. It feels like fitting a square peg into a round hole. Most workflows don't seem to need large asset support – only game development and other niches. But, I imagine if we solved it in an ergonomic way, we'd open up new workflows we never thought to do – like storing binary assets or database snapshots alongside code. Why not version everything if it's easy and cheap?

• Project Management Hooks, but not Features – Should issues and bug tracking be built into the version control system? That's the philosophy behind fossil. Project management is so amorphous and fleeting that I don't believe it should be built into foundational tech. Yet, a new VCS should expose the hooks and APIs that allow the flavor-of-the-moment project management tool to be built on top.