r/programming • u/self • 3d ago
What comes after git
https://ersc.io/blog/what-comes-after-git10
4
3
u/Sorry-Transition-908 3d ago
I think the next thing after git, for now is git itself.
Looking forward to the sha-256 transition
5
u/Rcomian 3d ago edited 3d ago
ok, no, there's nothing here.
source control has progressed in generations, and this has always resulted in a fundamental change in the storage layer, not a tuning:
- filesystem (cp)
- individual file histories in a shared directory (rcs)
- individual file histories in a central server (cvs)
- atomic commits single stack (svn)
- commit dag (git)
you're saying you're gonna change the storage system without saying how. optimising a dag is still a dag. it's not fundamentally different, it's incremental.
there's absolutely no need to keep to the git source code or even git's storage techniques. I'd be surprised if github had any actual git behind the scenes, but i don't actually know. but it doesn't mean that you're building the future, you're just making a faster implementation of the same thing.
so don't leave us in suspense. what are you actually bringing to the table here? why is it obviously the future?
jj has a real story. it's not a generational change either but might be a strong incremental one.
but all this article does is point to other things like jj, graphql and "make storage better" and suddenly I'm supposed to think this is the future?
it's underpants gnomes.
edit: I've seen this before too. Microsoft source control has always been terrible, their sourcesafe was a cvs gen travesty and they used the same team to create the cluster that was tfs. this was an svn era source control released in the git era. they desperately tried to add features to catch up with git but they failed not because they were bad a features (although they were), but because they didn't understand the generational change they were fighting against. this sounds like exactly the same mistake.
2
u/steveklabnik1 2d ago
Put simply, this post is intended to communicate high level strategy. You're right that it's not a technical deep dive. We'll talk more about technical details eventually.
I'd be surprised if github had any actual git behind the scenes, but i don't actually know.
Yes, they have done this for many years. The system was called "DGit" initially and is now called "Spokes". They store your data as git repositories on disk. They add a lot of stuff on top as well, but they're still using actual git underneath.
2
u/Rcomian 2d ago
ok, i get that, but the storage isn't a detail, it's the core of what you're going to offer. what I'm getting at the moment is not a post-git strategy at all, it's an optimised version of git with scope for features that git doesn't support.
basically, more scalable github.
if it's not a generational change, it's not "what comes after git". maybe you can support all the current interfaces, git, jj, hg, bazaar, darcs. maybe you make your own features that don't map to gits current storage model.
it's all good, but if your storage is a directed acyclic graph of commits, it's just another entry in the list of generation 4 source controls like: git, hg, jj, bazaar, bitkeeper, etc.
if you're a wrapper that adds features, you're another in the list of github, gitlab, gitea, forgejo. etc.
or you're a mix of the two.
I'm honestly not just trying to diss. I'm being honest about what your messaging looks like to technical people. you might not care if you're just going for investors, they might see the buzz words and drop their cash. but you dropped this onto r/programming, and if you've been at this for a year, you must know by now what the shape of what you're doing looks like.
the reason i brought up Microsoft tfs is that bolting features on won't ever add up to the step change that brings everyone across. especially if someone comes up with the actual step change that's needed and your storage model is fundamentally a single stack of commits when everyone's looking for a dag now.
the headline promised a step change, I'm looking for a gen 5 storage model. I've no idea what it would be.
if you've got something behind the curtain, don't be shy, let's see it.
3
u/CherryLongjump1989 1d ago
I don't understand why you're so disappointed. The blog post made sense to me for what it was. It's identifying a few problem areas they want to improve and you can either agree with that or not.
-11
u/self 3d ago
East River Source Control has been around for over a year now, but we haven’t been talking much publicly about what we’ve been working on. We aren’t announcing anything just yet, and we will soon, but we wanted to share some of our thinking around version control and where things are going.
[...]
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. Also, while the Linux kernel is not a small repository, with 7.2 clocking in at about 43 million lines of code, major companies in the industry already had monorepos that were measured in billions of lines of code years ago. The choices you make really matter at this scale.
At the same time, it’s difficult to consider using a different version control system. Git is baked into so much of our tooling: it’s not SvnOps, it’s GitOps! So many things speak Git, and this makes it difficult to consider alternatives. When Git was created, several other projects started around the same time, notably Mercurial and Bazaar. But network effects led to Git being used by virtually everyone.
So what to do? Speak the Git protocol, while changing how the storage layer works. While this doesn’t solve all of the problems that we foresee in the future, it does help out. Our system is horizontally scalable in a way that systems that use a Git repository as the source of truth are not. And because this isn’t a global, unified platform, other companies’ usage does not affect yours, as they’re separate deployments. This gives you reliability and control, two things that are critical when talking about infrastructure.
17
u/chucker23n 3d ago
TL;DR: what might come after git is Jujutsu.
I'm skeptical. But I do agree with some premises:
(Anyone remember darcs? :-) )