What Comes After Git(ersc.io) |
What Comes After Git(ersc.io) |
I’ve spent about 35+ years in and around version control / SCM, with half of that being part of the BitKeeper team, where my job was to think about sets, graphs, and weaves in the context of a team making commercial customers’ lives better along with benefit to open source world.
If Git is good enough for you, know that it is not true for everybody. For some subset of that everybody, it’s worth paying to have that pain go away. And part of having that pain go away is being able to stay connected to all that is, to be enough of a superset of the current world, to not be better in an incompatible way. That’s what I see in the pictures Steve and team draw: world that interacts with Git in a way that is better for some willing to pay to have the pain go away.
I agree nothing much is being said about the Non-Git Storage Engine. As I’ve spent half of my life in that world, I get it: secret sauce. I don’t expect much to be said for a while.
I realize this post is light on technical details. I expected this kind of reaction from HN, which is also fine. The goal here is more to share anything about what it is that we've been doing; a lot of people assumed that we were going to be coming out with a GitHub-style social coding forge for open source, and so on some level, this is us saying we're not going to be doing that. A lot of people also assumed we'd be focusing purely on jj, and so we wanted to make sure to talk about how we do care about git compatibility, even as we look to the future.
We'll be talking more about things as time goes on, but rather than never posting anything, this is the start of us stretching our muscles and being more involved in the public conversation around the future of version control. We've been too quiet!
My criticism of TFA is grounded less in refusing to tell us about the secret sauce than it is, uh, not giving us anything at all technologically substantive to chew on, I guess. I can certainly use my imagination given my own experience in these particular salt mines, and I know that Steve and team are good for the technology, but I'm nonetheless wondering who is intended to be TFA's audience.
Long live CDC Update!
> who is intended to be TFA's audience
I got something from seeing that last diagram. True, I don't know what features that future work will bring, but see that what ever it is, they want to keep it mappable to Git. Staying mappable to Git is a tether that can limit or reward creativity.
You posted before Steve's response[0]. Does that help?
I guess the question is: is that subset of people large enough to run a profit-making business on?
If you have some great reasons to say yes (Perforce, GitButler, ERSC) such as better technology targeting some industry, 2-way bridge to Git and connections in a market, then you wouldn't be listening to me.
If Git works well enough, great! If not, maybe a different system fits better[0].
I happen to have technical context around this problem[1], and I was rather underwhelmed by the announcement. At least mention how much of a pain in the ass the pack-protocol wire format is! Give those of us who are technical and knee-deep in Git's business something to commiserate over!
That all said, Fossil mentioned! \o/
--
0: Yeah, they mention agentic development patterns and constraints that monorepo-oriented patterns run up against, but the details are handwaved away. What about agentic development patterns in particular stress Git out? For those of us who don't use agents or have limited exposure to them, this isn't especially obvious, but the usage patterns are almost certainly reflected in other uses of Git that small-ish shops would encounter.
1: I've even looked long and hard at possibly taking my own crack at reworking Git's object store to be instead more like an append-only log, with an eye toward alleviating some of the problems that, e.g., heavy GitOps workflows can sometimes cause, let alone the fervor around agentic development. Like, this space is ripe for someone to come in and do it better, but version control is a technical tool for technical people.
And on March 11 another dev copied the key components of the idea, giving it the name “Fossil”, the same name of a project he had 20 years ago, to make it seem like a continuous, long-running project even though it was not actually launched until March 11, 2026.
Then Artifacts, Tangled (same dev who copied the same user on another project earlier), and a slew of other version control systems start getting attention here.
Kinda funny
If the main issue is agent-to-git overhead, until proven otherwise I see it as more of an agentic and/or UI issue than a source-versioning one.
This is supposed to be the most critical part of the blog post and it's really anemic. It never explains what's wrong with git.
I agree. Let's go back to subversion.
You can get claude to produce small, focused stacks, rather than 10,000 line monstrosities.
Their claim is consistent with Google's experience, but somewhat at odds with (say) that of FreeBSD, OpenBSD and NetBSD.
It's that those repositories are still orders of magnitude smaller than the ones that are inside of companies. Monorepos tend to be larger than polyrepos, due to the fact that you've got everything all in one repo, but that doesn't mean all monorepos must be truly large.
The real issue with the open vs closed bit is that features like "this subdirectory of the repository is only writable (or even visible!) to some people" is basically nonsense for open source, but valuable to a company monorepo. Their needs are just different.
outstanding.
Yes! It's one of those things I've carried over to bitty box distributed environments.
> You posted before Steve's response[0]. Does that help?
It does a little, yeah, but I'll admit that I still feel somewhat teased by it rather than properly informed. As I wrote, I'm close enough to the technical details of this problem that I'm able to use my imagination. I wouldn't be surprised if some of my own proposed designs mesh up with what Steve and co. are doing.
I just want some more concrete messaging "from the horse's mouth," as it were, about what's being undertaken to mitigate shortcomings in Git's architecture for folks in the enterprise space of technology and procurement stripes alike who might find it an interesting contrast to GitHub Enterprise.
It’s very possible some of your proposals are similar, I’m not familiar with them specifically so I can’t say. But there’s just a lot of stuff that’s already working in existing systems that just hasn’t been productized because those companies aren’t trying to get into the version control business.
If you’re familiar with citc/commit cloud, for example, we’ll be doing something along those lines. We think that workflow is very valuable for people.
We certainly know that people will want to know more details before they buy, and have shared stuff with prospective customers during the POC process. We’ll be more generally open about it over time.
If I can ever get around to writing about it or polishing up what I have enough that I feel comfortable with someone else looking at it, I'll poke you directly about some of what I've been working on over on the Fossil side of things.
> If you’re familiar with citc/commit cloud, for example, we’ll be doing something along those lines.
Oh, hey, yeah. I'm not first-hand familiar with that tooling (I've never been at Google), but there's a similar(-ish) workflow I've been kind of missing from Plan 9, so I've been hammering on that a little. Something like `m1 client connect $remote_url --name $client_name` and `m1 workspace bind M: --client_name $client_name --name $workspace_name`, which is a slightly more obtuse take on running `9fs` to authenticate and bind the sources server into the current namespace.
I've found that, at the time of a client connecting, there's a lot of value for me in having, like, the last however many commit manifests and seldom much else as far as file data goes. I can pull down the raw blocks containing that data on demand, and at least for now, commit manifests contain a complete enumeration of what's in the file tree at that commit. That's enough for me to rehydrate a browsable filesystem projection of the repository before I decide that I need to mirror blocks locally.