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.
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 much of that 35+ years in that world, I get it: secret sauce. I don’t expect much to be said for a while.
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?
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.
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
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.
> 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.
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?
No thanks. Get rid of the crypto slop and make something people want.
Better yet if you’re gonna do version control do something novel and stop playing off git entirely.
Be creative.
You rich kids are severely lacking in talent and originality.
HN promotes some of the most boring projects imaginable. I see more impressive stuff made by 9 year olds on YouTube than anything ATP/Bluesky team has ever done.
Even their Twitter app was just bad, not good design or engineering.
Consider giving up guys, it’s clear to me you don’t have what it takes to make anything good that people will use. You’re not the one that’s gonna do it, sorry.
Oh yeah and “jj” or whatever you have next is already a flop because of the team. Just like Bluesky.
Give up. You suck. You can’t think of anything fun or cool and you definitely can’t build it lol
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.
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 much of that 35+ years in that world, I get it: secret sauce. I don’t expect much to be said for a while.
> the value they might bring
Gtfo
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?
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.
What problem are they trying to solve? This part is still not very clear to me.
Being able to charge you for using git.
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
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
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.
> 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.
There's money to be made trying to replace git but not succeeding )
Yeah, but are investors really so stupid not to notice that even the problem statement doesn't actually hold any water?
>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.
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?
But it’s from 2005! And and it’s used for Linux. Ergo,
Tangled as in AT Proto?
No thanks. Get rid of the crypto slop and make something people want.
Better yet if you’re gonna do version control do something novel and stop playing off git entirely.
Be creative.
You rich kids are severely lacking in talent and originality.
HN promotes some of the most boring projects imaginable. I see more impressive stuff made by 9 year olds on YouTube than anything ATP/Bluesky team has ever done.
Even their Twitter app was just bad, not good design or engineering.
Consider giving up guys, it’s clear to me you don’t have what it takes to make anything good that people will use. You’re not the one that’s gonna do it, sorry.
Oh yeah and “jj” or whatever you have next is already a flop because of the team. Just like Bluesky.
Give up. You suck. You can’t think of anything fun or cool and you definitely can’t build it lol
It seems like the article makes a good point about Git staying here for a while.
Probably some A.I.-enabled version control system. I mean, everything has A.I. in it these days, right? Yawn!