Rendered at 21:17:07 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
nrr 14 hours ago [-]
I'll echo the other comments here: this article is really anemic on the details of how ERSC intends to retool Git for the future (beyond Jujutsu as a migration path) or why there isn't a place for Git (as we know it) in the future[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.
YouSkinwalker 4 hours ago [-]
A developer and user announced “Artifact” version control here on Feb 5th, 2026. Github still active. His post was deleted by admins.
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
rbsmith 9 hours ago [-]
This is more a response to many of the comments here than to the article, offering a perspective of what value they might bring.
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.
steveklabnik 40 minutes ago [-]
Thanks Rick!
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!
nrr 2 hours ago [-]
Oh, hey. Nice seeing you here. I appreciate your work blazing some interesting trails with graphs and weaves in distributed version control. (Though, I must admit that I'm still left sort of scratching my head at the concept in a bytestream-oriented world instead of in the record-oriented world where I have, say, a deck of JCL cards and for which record-level inclusions and exclusions make sense.)
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.
hn_submit 5 hours ago [-]
> For some subset of that everybody, it’s worth paying to have that pain go away.
I guess the question is: is that subset of people large enough to run a profit-making business on?
rbsmith 3 hours ago [-]
If you don't know otherwise, then no. Version control has always been a small market, and with Git, it's harder, because that sweet spot has been removed.
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.
sublinear 5 hours ago [-]
Once again, what is that "pain" exactly?
rbsmith 3 hours ago [-]
Depends on the industry and specifics of a company. Are they game developers with multiple sites? Is the customer a large company with a lot of vendor relationships using different systems? Are they a vendor of some customizable component used by many large companies? Is there a good integration with their bug tracking? Do they need to long term support of 25 years? Pain was in some part of their process that was constrained, maybe technical (workflow or integrations), maybe legal.
If Git works well enough, great! If not, maybe a different system fits better[0].
Like the other comments, I'm very confused at what this is meant to do other than promote a wanna-be Git competitor and yet another hyper-specific "conference". The post doesn't really make any arguments, even in the section that's suppose to make an argument. And for some reason they're adding GraphQL into the mix, somehow?
asmnzxklopqw 15 hours ago [-]
What problem are they trying to solve? This part is still not very clear to me.
happymellon 13 hours ago [-]
Being able to charge you for using git.
atprotosucks2 9 hours ago [-]
They’re literally just saying “me too”
That’s all these YC/HN rich kids know how to do.
They actually think nobody can tell they just rip off the public, do it worse, and then censor the OG
That is the HN way. Low iq uncreative dipshits with too much money
fergie 13 hours ago [-]
For me, the actual thing that git is not fantastic for is versioning data(bases), but this article doesn't seem to address that. In fact I am struggling to parse the article's proposed problem/solution.
12 hours ago [-]
Bayart 12 hours ago [-]
The article is vague, I'm having a hard time seeing if they're laying down a critique of git's underlying data representation and storage, a critique of git's UX or both.
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.
hn_submit 14 hours ago [-]
Probably some A.I.-enabled version control system. I mean, everything has A.I. in it these days, right? Yawn!
sublinear 15 hours ago [-]
> Put plainly, we do not believe that Git is the future of source control. Git has served developers well for many years, but it was designed around the constraints of 2005, not 2025, let alone 2035. For example, it was built for the Linux kernel: an open source project. Open Source is incredibly important to our industry, but this means it’s missing key features that are useful for organizations that aren’t sharing their code with everyone.
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.
steveklabnik 38 minutes ago [-]
Trying to keep it high level here. Explaining this is important, but it's just an entirely different kind of post. That post would be deep in the weeds, and this one is at a high level. Both matter, for sure. And we'll put out more technical posts as time goes on. But since we don't really have much on our blog just yet, we're starting with more abstractt stuff.
sam_lowry_ 14 hours ago [-]
There's money to be made trying to replace git but not succeeding )
holowoodman 13 hours ago [-]
Yeah, but are investors really so stupid not to notice that even the problem statement doesn't actually hold any water?
OhNoNotAgain_99 13 hours ago [-]
[dead]
HeckFeck 12 hours ago [-]
>it’s missing key features that are useful for organizations that aren’t sharing their code with everyone.
I agree. Let's go back to subversion.
coffeebeqn 13 hours ago [-]
But it’s from 2005! And and it’s used for Linux.
Ergo,
Almondsetat 13 hours ago [-]
Probably something about integrating access control to a repository so a deparment has the source for a certain library, while the others only see the header files and compiled objects to use?
quietraster 6 hours ago [-]
the versioning model question feels more urgent now that half my commits are written by agents. curious what the author thinks the right unit of change is when a diff is mostly machine generated
steveklabnik 8 minutes ago [-]
We are huge believers in stacked diffs, both for humans and machines. That said, everyone is trying to figure out what code review means in this new world, so we're open to things changing here.
You can get claude to produce small, focused stacks, rather than 10,000 line monstrosities.
PowerElectronix 12 hours ago [-]
It seems like the article makes a good point about Git staying here for a while.
gonzalohm 10 hours ago [-]
Giving "git was built for open source projects but not all projects are open source" as a reason why they think git won't work in the future is pretty weird
entrope 17 minutes ago [-]
That's not very close to the argument they make; the claim (right or wrong) is that large corporations often use monorepos, and those are bigger than single-project repositories like used for open source projects.
Their claim is consistent with Google's experience, but somewhat at odds with (say) that of FreeBSD, OpenBSD and NetBSD.
steveklabnik 14 minutes ago [-]
It's certainly not the case that no open source projects use monorepos, you are right that the BSDs do as well.
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.
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
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.
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].
[0] - https://www.inkandswitch.com/project/backstitch/
Gtfo
That’s all these YC/HN rich kids know how to do.
They actually think nobody can tell they just rip off the public, do it worse, and then censor the OG
That is the HN way. Low iq uncreative dipshits with too much money
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.
Your demented shit,
You think,
But, nope, that won't be it.