> The old model assumed one person, one branch, one terminal, one linear flow. Not only has the problem not been solved well for that old model, it’s now only been compounded with our new AI tools.
A bit of a strange thing to say in my book. Git isn't SVN and I think these problems are already solved with git. I agree that the interface is not always very intuitive but Git has the infrastructure which is very much focused on supporting alternatives to "one person, one branch, one terminal, one linear flow".
> the problem that Git has solved for the last 20 years is overdue for a redesign.
To me it's not clear what the problem is that would require a redesign.
Git was built because the commercial license of BitKeeper became unworkable for the Linux kernel community.
BitKeeper was free to linux kernel developers with a "but no reverse engineering" clause, but Tridgell went exploring of his own volition because he wanted to and kinda sorta violated that, so the license was cancelled by BitKeeper.
I'm not taking sides or upset about any part of this, I just wouldn't call that "becoming unworkable for the linux kernel community"; that would be like "the fence around your yard became unworkable for me in my desire to trespass on your property so I climbed over it"
what Tridgell discovered was pretty dumb and could be considered a distinct lack of a fence, but he connected to a socket and typed "help" and it dutifully printed out a bunch of undocumented useful commands.
Yep, something that is sadly becoming more and more common. People with solutions spending insane money trying to convince others that a problem exists.
Skill issue. It's the most popular VCS in the world by a huge margin, millions of devs use it every day just fine, countless forges have been built around it, and there's only one semi-compelling alternative frontend (jj). If you honestly find Git challenging, how are you coping with software engineering? Git is the easy part.
Millions of dev use it in the most rudimentary way, occasionally lose their stash, rm their local repo and start over, ask the office expert for help every time they need to figure out where-the-foxtrot that commit came from, don't even attempt to use reflog or bisect or interactive staging, etc.
> To me it's not clear what the problem is that would require a redesign.
The interface is still bad. Teaching people to use git is still obnoxious because it's arcane. It's like 1e AD&D. It does everything it might need to, but it feels like every aspect of it is bespoke.
It's also relatively difficult to make certain corrections. Did you ever accidentally commit something that contains a secret that can't be in the repository? Well, you might want to throw that entire repository away and restore it from a backup before the offending commit because it's so difficult to fix and guarantee that it's not hiding in there somewhere and while also not breaking something else.
It's also taken over 10 years to address the SHA-1 limitation, and it's still not complete. It's a little astonishing that it was written so focused on SHA-1 never being a problem that it's taken this long to keep the same basic design and just allow a different hashing algorithm.
> Well, you might want to throw that entire repository away and restore it from a backup before the offending commit because it's so difficult to fix and guarantee that it's not hiding in there somewhere and while also not breaking something else.
Of course is not true - look into git filter branch. I had to use it once when a developer checked in a whole bunch of binaries and created a PR which ended being merged. I had to rewrite the history and delete the files from history - just deleting the files would not suffice because the file were in git history and we’re taking too m&ch space.
The interface can be independent of the implementation. Under the hood git does everything you need. If learning to use it at a low level isnt appealing, then you can put an interface on top which is more ergonomic.
> Did you ever accidentally commit something that contains a secret that can't be in the repository?
What do I need to do on top of a git force push, and some well documented remote reflog/gc cleanup, which I can’t find with a single search/LLM request? Are we there, where we don’t have enough developers who can do this without feeling it as a burden? Or are we there where this level of basic logic is not needed to implement anything production ready?
This is not the problem they are redesigning for, they are redesigning the infrastructure. Github is a live example of a different interface on top of git and that is working fine (though some may have their complaints with it), no redesign of git's underlying "infrastructure" needed.
> Did you ever accidentally commit something that contains a secret that can't be in the repository?
This is an inconvenience for secrets (have become more commonplace since the creation of git) but by my understanding this was a very deliberate choice in the design of git. It grantees integrity in the distributed source. For example you can check the hash of the last commit en be sure that your mirror did not inject malicious code.
I've always wanted a kind of broader and more integrated approach that isn't just about text diffs. the ability to link in substantial comments that would be displayed optionally and not piss off linear readers. links to design and reference documents. bugs and prs that were persistent and linked to the versioned code instead of being ephemeral.
think about all of the discussion we have around the code that gets lost. we certainly have the ability to keep and link all that stuff now. we don't really need to have arguments about squashing or not, we can just keep the fine grained commits if you really want to dig into them and maybe ask that people write a comprehensive summary of the changes in a patch set -in addition-.
but I guess none of that has anythig to do with AI
A lot of people seem confused about how they raised the money, but it’s actually a pretty easy VC pitch.
- It’s from one of GitHub’s cofounders.
- GitHub had a $7.5B exit.
- And the story is: AI is completely changing how software gets built, with plenty of proof points already showing up in the billions in revenue being made from things like Claude Code, Cusor, Codex, etc.
So the pitch is basically: back the team that can build the universal infrastructure for AI and agentic coding.
I recently switched to Jujutsu (jj) and it made me realize that “what comes after Git” might already exist.
It turns out the snapshot model is a perfect fit for AI-assisted development. I can iterate freely without thinking about commits or worrying about saving known-good versions.
You can just mess around and make it presentable later, which Git never really let you do nicely.
Plus there’s essentially zero learning curve, since all the models know how to use JJ really well.
Installed GitButler to try it out — and realized it installs malicious Git hooks to take over the git commit workflow:
* pre-commit — The malicious one. It intercepted every git commit attempt and aborted it with that error message, forcing you to use but commit instead. Effectively a commit hijack — no way to commit to your own repo without their tool.
* post-checkout — Fired whenever you switched branches. GitButler used it to track your branch state and sync its virtual branch model. It cleaned this one up itself when we checked out.
* There's also typically a prepare-commit-msg hook that GitButler installs to inject its metadata into commit messages, though we didn't hit that one.
* The pre-commit hook is the aggressive one — it's a standard git hook location, so git runs it unconditionally before every commit. GitButler installs it silently as part of "setting up" a repo, with no opt-in. The only escape (without their CLI) is exactly what we did: delete it manually.
The tool that could replace git must free, ubiquitous, and arguably open-source. This is why I cannot imagine how raising $17M may pay for itself in that case, to say nothing of a 10× return.
It may be a great tool, but I'd be very reluctant to use a closed-source solution as a cornerstone of infrastructure.
756 comments
> The old model assumed one person, one branch, one terminal, one linear flow. Not only has the problem not been solved well for that old model, it’s now only been compounded with our new AI tools.
A bit of a strange thing to say in my book. Git isn't SVN and I think these problems are already solved with git. I agree that the interface is not always very intuitive but Git has the infrastructure which is very much focused on supporting alternatives to "one person, one branch, one terminal, one linear flow".
> the problem that Git has solved for the last 20 years is overdue for a redesign.
To me it's not clear what the problem is that would require a redesign.
"Those who cannot remember the past are condemned to repeat it".
>
Git was built because the commercial license of BitKeeper became unworkable for the Linux kernel community.BitKeeper was free to linux kernel developers with a "but no reverse engineering" clause, but Tridgell went exploring of his own volition because he wanted to and kinda sorta violated that, so the license was cancelled by BitKeeper.
I'm not taking sides or upset about any part of this, I just wouldn't call that "becoming unworkable for the linux kernel community"; that would be like "the fence around your yard became unworkable for me in my desire to trespass on your property so I climbed over it"
what Tridgell discovered was pretty dumb and could be considered a distinct lack of a fence, but he connected to a socket and typed "help" and it dutifully printed out a bunch of undocumented useful commands.
> To me it's not clear what the problem is that would require a redesign.
The interface is still bad. Teaching people to use git is still obnoxious because it's arcane. It's like 1e AD&D. It does everything it might need to, but it feels like every aspect of it is bespoke.
It's also relatively difficult to make certain corrections. Did you ever accidentally commit something that contains a secret that can't be in the repository? Well, you might want to throw that entire repository away and restore it from a backup before the offending commit because it's so difficult to fix and guarantee that it's not hiding in there somewhere and while also not breaking something else.
It's also taken over 10 years to address the SHA-1 limitation, and it's still not complete. It's a little astonishing that it was written so focused on SHA-1 never being a problem that it's taken this long to keep the same basic design and just allow a different hashing algorithm.
> Well, you might want to throw that entire repository away and restore it from a backup before the offending commit because it's so difficult to fix and guarantee that it's not hiding in there somewhere and while also not breaking something else.
I'm not a git expert but I cant image that's true
> Did you ever accidentally commit something that contains a secret that can't be in the repository?
What do I need to do on top of a git force push, and some well documented remote reflog/gc cleanup, which I can’t find with a single search/LLM request? Are we there, where we don’t have enough developers who can do this without feeling it as a burden? Or are we there where this level of basic logic is not needed to implement anything production ready?
> The interface is still bad.
This is not the problem they are redesigning for, they are redesigning the infrastructure. Github is a live example of a different interface on top of git and that is working fine (though some may have their complaints with it), no redesign of git's underlying "infrastructure" needed.
> Did you ever accidentally commit something that contains a secret that can't be in the repository?
This is an inconvenience for secrets (have become more commonplace since the creation of git) but by my understanding this was a very deliberate choice in the design of git. It grantees integrity in the distributed source. For example you can check the hash of the last commit en be sure that your mirror did not inject malicious code.
> The old model assumed one person, one branch, one terminal, one linear flow.
That sounds exactly like the pre-git model that git solved..
think about all of the discussion we have around the code that gets lost. we certainly have the ability to keep and link all that stuff now. we don't really need to have arguments about squashing or not, we can just keep the fine grained commits if you really want to dig into them and maybe ask that people write a comprehensive summary of the changes in a patch set -in addition-.
but I guess none of that has anythig to do with AI
The problem that requires a redesign is that vcs are unable to extract a subscription rent from some of the people who use git.
- It’s from one of GitHub’s cofounders.
- GitHub had a $7.5B exit.
- And the story is: AI is completely changing how software gets built, with plenty of proof points already showing up in the billions in revenue being made from things like Claude Code, Cusor, Codex, etc.
So the pitch is basically: back the team that can build the universal infrastructure for AI and agentic coding.
It turns out the snapshot model is a perfect fit for AI-assisted development. I can iterate freely without thinking about commits or worrying about saving known-good versions.
You can just mess around and make it presentable later, which Git never really let you do nicely.
Plus there’s essentially zero learning curve, since all the models know how to use JJ really well.
* pre-commit — The malicious one. It intercepted every
git commitattempt and aborted it with that error message, forcing you to usebut commitinstead. Effectively a commit hijack — no way to commit to your own repo without their tool.* post-checkout — Fired whenever you switched branches. GitButler used it to track your branch state and sync its virtual branch model. It cleaned this one up itself when we checked out.
* There's also typically a prepare-commit-msg hook that GitButler installs to inject its metadata into commit messages, though we didn't hit that one.
* The pre-commit hook is the aggressive one — it's a standard git hook location, so git runs it unconditionally before every commit. GitButler installs it silently as part of "setting up" a repo, with no opt-in. The only escape (without their CLI) is exactly what we did: delete it manually.
It may be a great tool, but I'd be very reluctant to use a closed-source solution as a cornerstone of infrastructure.