I absolutely love jj (just check my HN comment history). One thing I'd love to see in jj though that git does better is copy tracking. If somebody renames a file upstream, and you go to rebase your commit that touches that file onto main, jj doesn't handle this very well compared to git.
Do you have any idea if this is coming to jj soon?
Will this have any chance if Jujutsu/jj doesn't get more traction? The effort to learn a new VCS is less than for a programming language, but many developers have not learned git in depth, and Mercurial and others have not gained a lot of traction.
jj is one of the few new devtools I was quite frustrated with while starting out but could see the value so stuck around and man is it so nice.
For anyone curious the big thing with jj is you can undo. Basically if you were running a rebase and bungled a commit sha or branch name, no worries undo your way out, if you forgot to push but abandoned a commit not issues undo it. Same with all jj commands.
Delta db takes this a step further and everything you edit is a change so your actual edits are also all saved.
I find non destructive-ness for as long as possible approach very nice, since there aren't as many constraints on us not being able to do it nowadays, we had limited storage and stuff in 2000s perhaps but in 2026 even with the killer SSD prices it's fairly cheap to buy more SSD, we can definitely waste 100MB per project storing redundant history we may not ever need.
Same way in photoshop non destructive editing took over, especially useful for humans, but works for AI and LLMs too, they can undo their mistakes as well.
A term coined within Google that describes the best part (to me at least) of jj: delayed conflict resolution.
You worked on multiple things, you sync with the upstream, then boom now you have conflicts in one or more of your local branches.
Instead of immediately presenting you a conflict resolution view (usually 3 pane vimdiff) and you'll have to resolve at the sync time, the commits are simply marked as "have conflict", and you can continue working on other things until you have time to deal with it.
And for a chain of commits that all have conflicts, chances are fixing the first conflict automatically resolves all other conflicts in the chain, thanks to the auto-rebasing feature.
> And for a chain of commits that all have conflicts, chances are fixing the first conflict automatically resolves all other conflicts in the chain, thanks to the auto-rebasing feature.
What happens if one is unlucky and the conflicts are not automatically resolved from changes to the first commit? Does that potentially imply more work overall than if one was using a VCS that forced conflict resolution earlier, like git?
Someone will have to explain the value proposition to me...
We have git.
jujutsu works with git.
git can do everything jujutsu can do (otherwise, jujutsu couldn't work with git).
Thus, jujutsu is a UX / new steering wheel.
ERSC is trying to be a GitHub competitor with what surplus value?
Don't get me wrong, GitHub has a slew of its own problems, but I have not seen any commentary on how ERSC addresses any of the downfalls GitHub has too. We're jumping from one frying pan into another, currently-cooler one?
What about SourceHut? Codeberg? They could offer the same steering wheels.
We'll be saying more about this very soon, but the short version is this: we are not building a GitHub competitor in the way that SourceHut or Codeberg are. We are building infrastructure for enterprises, not a social coding site.
While jj works with git, it doesn't have to. jj has the ability to work with many backends. Git is the popular one in the open source world, but that doesn't mean that other ones are not possible. And that's the core tech we have built.
With the rise of agents, more and more companies are running into the limits of what Git can do. It was never designed for large monorepos, and so there are performance issues, but also features that it's missing, that are important once you start trying to scale things up to an entire organization. Companies like Meta and Google ran into these things well before the present moment, but you don't have to be a FAANG these days to be running into this sort of stuff.
We also understand that incremental adoption is really important, especially for something as fundamental as source control. So our tech also has a git ingress/egress that will work with the core functionality, but more advanced things that git simply can't do will end up requiring using a non-git protocol. jj is the bridge between those two worlds.
I hope that makes sense! We have been in psudeo-stealth for a while now, this is the start of us coming out of our shell a bit and actually talking about what we're doing.
It's not so much that we will prevent individuals from using the product, we are just focusing feature development on the needs of companies and teams. Startups are hard, and you have to focus, and so that's where we are focusing first.
Will you prevent individuals from using the product by requiring a sales call for onboarding? (aka: decisions that have nothing to do with individuals at all, but merely rule them out by intrinsically not being something they can achieve)
As we initially roll out we will be doing that, yes. The reason is that our initial offering is enterprise shaped, and so won't have a self-service onboarding. Eventually we will not require the white gloves, but you have to start somewhere.
This sounds glib, but I mean it sincerely: we will make money by charging money to use the product. A free tier on source control hosting is just not economically tenable nowadays. I have built a career on open source, and so that bums me out, but we have a business to run.
Our moat is that we are not trying to take git and scale it up, we are building a more scalable system from the beginning. And we will have features that nobody else has because of it.
It's always the case that businesses have competitors, that's just capitalism. We're not worried about that.
I might be mistaken, but I always figured the end goal for jujitsu was to use its own backend. Supporting git-colocation seems like a compatibility case to bring users over.
If I had to guess, then I would say ERSC is trying to build a `jj` forge based on this new hire and that would be amazing imo.
> git can do everything jujutsu can do (otherwise, jujutsu couldn't work with git).
FWIW I think it's a bit more nuanced than that. As a trivial counter example Git does not currently have a way to store conflicts inside commits[1], which is one of our major features. The way this works is that we basically store the sides of the conflicting trees in the Git object database (and another conflicted tree pointing to all of them), but the actual data structure representing the conflict as Jujutsu understands it is stored elsewhere. Git will be very confused looking at a conflicted tree object created by Jujutsu -- it shouldn't break but it doesn't understand what it's seeing. So, if a object can be stored in the database that is correct but Git can't really "view" it properly, does "git" (or capital-G Git) support it or not? Depends on who you ask, I guess. The storage layout being intimately tied to Git "as a thing", part of its identity, is one of the most interesting properties it has.
The way I see it is this. Jujutsu uses the Git storage layout on disk. But basically all of the algorithms and UX between the two are completely different. That is where most of the real differences are. To the extent we integrate with lots of fiddly Git details (eg tracking branches, remote integration etc) so that `git` commands work -- that's more necessity to make the UX nice. We could absolutely use the on disk Git format but in a way that was inscrutible to the `git` CLI, it just obviously would not be very nice.
As a disclosure I work at ERSC but I am also one of the maintainers of Jujutsu; this post is written with my maintainer hat on.
[1] At Git Merge last year, Elijah Newren prototyped and demo'd a really early and cool example of storing first class conflicts in Git, based on his work on ort-merge. So this might not be true forever :)
> As a trivial counter example Git does not currently have a way to store conflicts inside commits[1], which is one of our major features.
Yes, I like how jj does it!
Did a big `git rebase -i` yesterday and I felt stressed up, almost a bit angry, when there were some conflicts and I wasn't sure if I'd resolve all of them before it was time to leave, and work more later from a different laptop.
But with jj, no stress: I can just check in the conflicts, and later, on the other laptop: check out the conflicts and continue resolving.
(I just wish there was Git submodule support :- ))
"Can do" and "can do easily" or "can do with minimal friction" aren't the same.
I use JJ locally and for those that call it a "porcelain" or a "git UI" are missing a lot. Sure you can use it that way, but what I've found is that it facilitates (and perhaps encourages) a pretty different workflow than I'd use with just plain Git. I could pull off what I do in JJ in just plain Git... but it wouldn't at all feel natural and you can really see this when you start using a JJ driven repository with Git tools (including just the Git command line tools).
Personally, and as a mere version control user, I prefer the JJ model of version control much more than Git's. The mechanics of the UI was very easy to get under my fingers (the essentials in about a day), but getting the ideas and really getting an understanding/appreciation for the conceptual differences and their ramifications on workflow took a month or two of regular working and trying things. For me, it was worth the effort.
I don't know how experienced you are with jj, but one thing I can say for sure is jj offers significant ux improvements over git and they plan to have a backend eventually. we might see the first implementation from ersc. and from their website I see they are already taking things like agents into account from day one. so we might be in the verge of getting something that scales better with modern day workload?
tell that to Doug Englebart or J.C.R. Licklider-- the idea of human-computer symbiosis predates basically all computers that we would recognize as such today. crazy how it is only really now becoming true in the way that they envisaged in the 1960s.
It's in the post, but Martin will be continuing to work on jj itself as well as on our products, just as he did at Google, working on the open source jj but also their internal source control team.
As a side note, jj has rules around company representation in maintainership, and so when this initially happened a few months back, ERSC actually became over-represented in the maintainers group, as we also employ several other maintainers. The project decided to add more maintainers to keep the balance, rather than ask folks to step down.
We very much want to properly support the upstream project, and we want to make sure that it continues to be awesome for everyone, not just our customers.
No worries, Windows 11, browser I just tested in Opera and Edge. Shared Intel GPU runs at 70% in either, guessing due to the lovely clouds drifting by.
We liked our old look, but one funny thing about how things are going in the world: our old color scheme was too close to what happens when you ask Claude to generate a site, and so even though we paid a human to build it, we didn't want to communicate slop, especially because that's not what we did!
Nick Noble is our designer, he put in a bunch of work on this, and I really like it too.
I love how little latency there is on your website. I'm often thrown off by websites freezing on navigation, something we euphemistically call "loading". I feel we should have moved beyond that in the year of 2026. Your website really respects the user in this regard. Aesthetics are splendid as well.
Jujutsu is apparently the name of a version control system, for anyone else confused how the creator of a thousand year old martial art had joined them.
Thanks, I was trying to work it out in my head. I knew brazilian jiu jitsu was 20th century, and I was like "but wait, is jiu jitsu itself not that much older, that seems very surprising."
Without having tried JJ, as a hype chaser, I can say it's both worth it and not worth it.
I run NixOS, work with Kubernetes, code Rust, use a 40% split, layered keyboard with Dvorak layout and open source firmware, kaj mi parolas Esperanton.
They're just hobbies that, once you've sunk the hours in, they're awesome.
I don't actually type faster. Or maybe I do type a little faster because it made me use all 12 fingers instead of the ad-hoc 7-finger system you taught yourself in primary school, but typing was never a bottleneck, and split keyboards actually hurt my wrists more.
Jujutsu is marginally better than git, but costs time. If you like to spend the time, it will probably make you a little better. If you care deeply about your time, and it's already being allocated for anything but arbitrary intellectual pursuit, it's not worth it. Some people grow businesses, plants, or sedentary habits.
Do you have any idea if this is coming to jj soon?
btw, did Martin leave google?
Martin left Google for this, yes.
If you haven't tried jj yet, take it for a spin and see how you like it.
For anyone curious the big thing with jj is you can undo. Basically if you were running a rebase and bungled a commit sha or branch name, no worries undo your way out, if you forgot to push but abandoned a commit not issues undo it. Same with all jj commands.
Delta db takes this a step further and everything you edit is a change so your actual edits are also all saved.
I find non destructive-ness for as long as possible approach very nice, since there aren't as many constraints on us not being able to do it nowadays, we had limited storage and stuff in 2000s perhaps but in 2026 even with the killer SSD prices it's fairly cheap to buy more SSD, we can definitely waste 100MB per project storing redundant history we may not ever need.
Same way in photoshop non destructive editing took over, especially useful for humans, but works for AI and LLMs too, they can undo their mistakes as well.
You worked on multiple things, you sync with the upstream, then boom now you have conflicts in one or more of your local branches.
Instead of immediately presenting you a conflict resolution view (usually 3 pane vimdiff) and you'll have to resolve at the sync time, the commits are simply marked as "have conflict", and you can continue working on other things until you have time to deal with it.
And for a chain of commits that all have conflicts, chances are fixing the first conflict automatically resolves all other conflicts in the chain, thanks to the auto-rebasing feature.
What happens if one is unlucky and the conflicts are not automatically resolved from changes to the first commit? Does that potentially imply more work overall than if one was using a VCS that forced conflict resolution earlier, like git?
We have git.
jujutsu works with git.
git can do everything jujutsu can do (otherwise, jujutsu couldn't work with git).
Thus, jujutsu is a UX / new steering wheel.
ERSC is trying to be a GitHub competitor with what surplus value?
Don't get me wrong, GitHub has a slew of its own problems, but I have not seen any commentary on how ERSC addresses any of the downfalls GitHub has too. We're jumping from one frying pan into another, currently-cooler one?
What about SourceHut? Codeberg? They could offer the same steering wheels.
While jj works with git, it doesn't have to. jj has the ability to work with many backends. Git is the popular one in the open source world, but that doesn't mean that other ones are not possible. And that's the core tech we have built.
With the rise of agents, more and more companies are running into the limits of what Git can do. It was never designed for large monorepos, and so there are performance issues, but also features that it's missing, that are important once you start trying to scale things up to an entire organization. Companies like Meta and Google ran into these things well before the present moment, but you don't have to be a FAANG these days to be running into this sort of stuff.
We also understand that incremental adoption is really important, especially for something as fundamental as source control. So our tech also has a git ingress/egress that will work with the core functionality, but more advanced things that git simply can't do will end up requiring using a non-git protocol. jj is the bridge between those two worlds.
I hope that makes sense! We have been in psudeo-stealth for a while now, this is the start of us coming out of our shell a bit and actually talking about what we're doing.
You mention performance issues with Git, but there are performance issues with this blog post.
Our moat is that we are not trying to take git and scale it up, we are building a more scalable system from the beginning. And we will have features that nobody else has because of it.
It's always the case that businesses have competitors, that's just capitalism. We're not worried about that.
If I had to guess, then I would say ERSC is trying to build a `jj` forge based on this new hire and that would be amazing imo.
FWIW I think it's a bit more nuanced than that. As a trivial counter example Git does not currently have a way to store conflicts inside commits[1], which is one of our major features. The way this works is that we basically store the sides of the conflicting trees in the Git object database (and another conflicted tree pointing to all of them), but the actual data structure representing the conflict as Jujutsu understands it is stored elsewhere. Git will be very confused looking at a conflicted tree object created by Jujutsu -- it shouldn't break but it doesn't understand what it's seeing. So, if a object can be stored in the database that is correct but Git can't really "view" it properly, does "git" (or capital-G Git) support it or not? Depends on who you ask, I guess. The storage layout being intimately tied to Git "as a thing", part of its identity, is one of the most interesting properties it has.
The way I see it is this. Jujutsu uses the Git storage layout on disk. But basically all of the algorithms and UX between the two are completely different. That is where most of the real differences are. To the extent we integrate with lots of fiddly Git details (eg tracking branches, remote integration etc) so that `git` commands work -- that's more necessity to make the UX nice. We could absolutely use the on disk Git format but in a way that was inscrutible to the `git` CLI, it just obviously would not be very nice.
As a disclosure I work at ERSC but I am also one of the maintainers of Jujutsu; this post is written with my maintainer hat on.
[1] At Git Merge last year, Elijah Newren prototyped and demo'd a really early and cool example of storing first class conflicts in Git, based on his work on ort-merge. So this might not be true forever :)
Yes, I like how jj does it!
Did a big `git rebase -i` yesterday and I felt stressed up, almost a bit angry, when there were some conflicts and I wasn't sure if I'd resolve all of them before it was time to leave, and work more later from a different laptop.
But with jj, no stress: I can just check in the conflicts, and later, on the other laptop: check out the conflicts and continue resolving.
(I just wish there was Git submodule support :- ))
I use JJ locally and for those that call it a "porcelain" or a "git UI" are missing a lot. Sure you can use it that way, but what I've found is that it facilitates (and perhaps encourages) a pretty different workflow than I'd use with just plain Git. I could pull off what I do in JJ in just plain Git... but it wouldn't at all feel natural and you can really see this when you start using a JJ driven repository with Git tools (including just the Git command line tools).
Personally, and as a mere version control user, I prefer the JJ model of version control much more than Git's. The mechanics of the UI was very easy to get under my fingers (the essentials in about a day), but getting the ideas and really getting an understanding/appreciation for the conceptual differences and their ramifications on workflow took a month or two of regular working and trying things. For me, it was worth the effort.
I don't know how experienced you are with jj, but one thing I can say for sure is jj offers significant ux improvements over git and they plan to have a backend eventually. we might see the first implementation from ersc. and from their website I see they are already taking things like agents into account from day one. so we might be in the verge of getting something that scales better with modern day workload?
As a side note, jj has rules around company representation in maintainership, and so when this initially happened a few months back, ERSC actually became over-represented in the maintainers group, as we also employ several other maintainers. The project decided to add more maintainers to keep the balance, rather than ask folks to step down.
We very much want to properly support the upstream project, and we want to make sure that it continues to be awesome for everyone, not just our customers.
> von Zweigbergk will continue to be a core maintainer of JJ as an open source project under the Apache 2.0 license.
Looking forward to using the VCS stuff you'll create :- )
Rust is the default language for all of our non-frontend web stuff, yes.
There will be a lot more of it soon :D
We liked our old look, but one funny thing about how things are going in the world: our old color scheme was too close to what happens when you ask Claude to generate a site, and so even though we paid a human to build it, we didn't want to communicate slop, especially because that's not what we did!
Nick Noble is our designer, he put in a bunch of work on this, and I really like it too.
(Martin joined back then, but we are posting about it today, so we should have the post date as today)
I wrote about why I joined the company back when I did previously here: https://steveklabnik.com/writing/i-see-a-future-in-jj/
In short: we are building a next generation source control system for the enterprise.
We should be respecting https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A... . If we do not, that's a bug, and please let me know what browser/OS/whatever else combo you have if that is an issue.
I run NixOS, work with Kubernetes, code Rust, use a 40% split, layered keyboard with Dvorak layout and open source firmware, kaj mi parolas Esperanton.
They're just hobbies that, once you've sunk the hours in, they're awesome.
I don't actually type faster. Or maybe I do type a little faster because it made me use all 12 fingers instead of the ad-hoc 7-finger system you taught yourself in primary school, but typing was never a bottleneck, and split keyboards actually hurt my wrists more.
Jujutsu is marginally better than git, but costs time. If you like to spend the time, it will probably make you a little better. If you care deeply about your time, and it's already being allocated for anything but arbitrary intellectual pursuit, it's not worth it. Some people grow businesses, plants, or sedentary habits.
I also use jj as my daily driver now. I like it a lot. I have no skin in the game either.