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?
Technically, you can still tell actually - jj writes a "change-id xyz..." in the git commit object header, which remains there as it's pushed around. It's just typically not made visible by regular things. (I wonder what other random garbage has been hidden in git commit headers that noone has seen)
I like to compare Google and jj to Mozilla and Rust: Google employed Martin and some other maintainers, but it's always been an OSS project under the Apache 2.0 license.
That being said, there's a few things that lead to this perception: the first is that it used to be under Google's GitHub account, but is now under its own org. The second is that contributing to jj does require signing Google's CLA. That is something that is desired to change, but that's up to Google. Due to the license, the community could fork it, and still have the rights to use the code, but that would be pretty aggressive, and so everyone involved would rather work together on this than do so. The move to its own GitHub org was one example of movement in that direction, but I'm not aware of an actual timeline to remove the CLA just yet. The project will figure it out over time.
(I have a commit bit but am not a jj maintainer, so the above is my own impression from being involved in the community for the past few years.)
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.
I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint (lots of inconsistent naming of things and somewhat leaky abstractions), and that Mercurial faced an uphill battle in large part because it lacked compatibility with what people were already using. I haven't used Mercurial, but from what I've heard quite a lot of how jj does things is similar to Mercurial, just in a way that's compatible with git. I haven't used git directly for over a year in favor of using jj despite exclusively using git repositories, and no one I've worked with has even needed to be aware.
> I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint
Not really. I remember my early years with git and the favt was that I never needed more than clone, add, commit, pull and push. While I’ve done some mistakes that got ne to learn more, especially with creating branches and undoing. I’ve never needed a lot, even when I started using GUI which exposed more concepts.
Why? Because I have no understanding of version management and how it’s useful in a dev workflow/release process. I was just using it for checking in work.
Since then, I’ve read the “Pro Git” book, learned how devs and teams handle versioning and devel a good understanding of how git can help me in my coding process and general software development. And it’s very good at what it does.
I like the idea of jujutsu, but I must not operate at a scale where its "killer features" would truly shine. Git hardly ever gets in my way, I have never had to do complex octopus merges or anything like that. It's usually: feature branch, implement, merge, and occasionally fix a merge conflict. JJ seems like it's more for people that like to have tons of active branches that they are constantly switching between whereas I usually only work on 1 thing at a time. I've never thought to myself "git is so frustrating I wish there were something better" because I only use the same 5 commands over and over every day and they never get in my way. Not to mention jj has its own share of esoteric syntax with all the "@--+::" business and I'd have to re-wire my brain to remember those symbols instead of `ref~N`, etc.
I was a skeptic until a few months ago. It’s my daily driver now. I’ve got sizable amount of people committing to the same repo, many are not skilled with git. So I deal with weird crazy “how did you ever get the repo into this state” issues not infrequently.
JJ is just so low friction. The seamless and painless shuffling of commits, working up and down the commit chain without explicit rebasing, unchanging change-ids. The min identifiers in change-ids being highlighted. Being able to make commits and worry about the message later. Snapshots of changes while you are working serving as a tool agnostic undo.
Painless and sensible cli args that are vastly more consistent than git.
Superior conflict handling.
You can “jj undo” anything and it works perfectly.
It’s fabulous.
> "@--+::"
I have no idea what that means and I’ve never had to type anything remotely like it.
The rev specification language is pretty elaborate but you don’t need to know it.
Same experience. At first I really didn’t get it and now I could never go back. The ease of rebasing, renaming, reordering, splitting, etc. Has drastically changed the way I work. My PRs are undoubtably much better now, and I am never afraid of messing up thanks to jj undo and the op log in general
A few advantages for me, even for the same 5 commands I use over and over:
- undo
- shuffling commits around with squash, split, and rebase is much better than git’s interactive rebase
- make commits without having to come up with a branch name (I might make three versions of the same change in parallel to see how they compare)
I see git is working on adding some of this under the history command. The revset language is really not esoteric: @ is head, @—- is two behind head. That’s about it.
Part of it is that the sorts of shuffling I used to avoid because they were a pain in git (so I didn’t feel I needed them improved) are so easy in jj that I do them all the time.
Similar to you, 95% of the time I do the simple use case that I've memorized. The problem is that even after a decade of using Git, when I get into those 5% where something goes wrong, I have no idea how to actually solve it. None of it makes any sense in my head, and I have to search for a bunch of magical commands to run, or nuke things to get back to a good state.
With JJ, it just makes sense. It's intuitive and clear. I have been able to recover without any help. Just the undo alone is basically a life saver. Rebasing and merge conflict resolution is so much simpler.
Yes I probably won't use it to its full potential, but still, the little I do use makes 10x more sense than Git ever did.
I don’t know about you, but if you ever run git commit --amend, git rebase -i, git reset, git reset --hard, git stash, git add ., git push --force-with-lease, then these are all workflows that jujutsu makes easier and less error-prone.
if you make commits, then you are at the scale where its killer features would shine. In other words, even the most basic git usage is made easier with jj.
If you care to learn more, there's tons of posts on hn and the broader web, so I won't bother sharing any links. I will say, though, that you should use it with jjui, which is a tremendous TUI for jj - you don't even really need to learn any of the actual jj syntax because it just handles it all for you.
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.
Edit: Thank you to everyone who replied. The enterprise/teams infrastructure angle makes sense.
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.
All but one of my employers have used either Github or Gitlab, and at every one of them there were a litany of complaints about whichever one we were using. It's kind of surprising to me that someone might not immediately recognize that there's certainly potential there for something better suited to what companies are actually looking for. Obviously there's no guarantee of success, and maybe the problem is too hard to solve, but that's pretty much how any company starts out!
I think it’s partly about how many steps back you take. Take another step back and you might see a new option that will in ten years be added to your list of options lots of people use and have plenty of complaints about.
I’m not saying not to try or that there’s no value in turning the wheel once more. But I used to be excited about these kinds of things and now I’m not because I’ve seen the cycle a few times now.
I’m very excited to see the great work ERSC has/will do. When thinking about where Git lags today, I’ve come up with three categories: UX features and custom data not natively understood by the Git CLI, a stock git-http-backend that doesn’t scale well to moderate monorepo size in server compute / storage, and a wire protocol that isn’t as flexible as it could be for special requests.
But there are so many hooks into the Git workflow today, and I’m struggling to find a “user story” that would not be met by custom Git tooling. UX could be added to Git objects à la Gerrit with custom CLIs, custom Gitoxide ODB and (eventually) ref storage backends can help the server scale, and things like promisor remotes and partial clones can keep things smaller on the client side.
I’m curious what ERSC is able to share publicly about where the scaling fails with the Git specification? Is it the wire format, or the relative speed of upstreaming new things to Git? Or is the side-channel approach for storing rich data in Git objects insufficient in some way?
P.S. I wrote a blog post[1] about this a bit ago. I’m sure I’m missing something. Since I wrote it, I’ve wondered if the lack of deferred conflicts in-tree would be a scaling limiter.
Yes, it's important to realize that git is multiple things: the on-disk repo format, the CLI, and the wire protocol. Each has their own challenges, just like any project, but they can be tackled independently. But at the end of the day, there just are fundamental limits to the way that git does things that make total sense in the context Linus developed git for, but just do not in other ones. Some of those are performance related, but some of those are things like how the kernel is an open source project, and so per-directory ACLs are something that git wouldn't ever bother supporting, but are valuable for companies. We'll be talking about these things in the future, so I'm just going to be hand-wavy about it right now. But we do think that git is a really great system that has served us all well for 20 years, but just like how git displaced systems before it due to significantly re-thinking the details, for some users, making meaningful improvements over git will also require a similar significant re-think. That's just the way of technological development.
As someone trying to compete in this space: will ERSC make the change/commit their unit of code review? It's one of the pet peeves I have with GitHub et al.
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.
I think it's unlikely that individuals will need their product, unless you happen to have a 100 million line monorepo. (At least based on what it sounds like they're targeting.)
Normal Git/JJ is fine for most people, and most open source projects. It's just when you get to the scale of commercial software companies (100+ employees) you run into the classic monorepo/submodule problem.
Monorepos are currently the best solution - they make testing tractable, you can do cross-project changes, Git's support for them isn't buggy as hell. But they have obvious downsides - performance is the big one, but also integration with open source projects, permission control, etc.
So there's this big problem space that really only matters to companies where as far as I know there are currently no good open source or even commercial solutions. The only people that have (maybe) solved it are the mega-corps like Facebook and Google who have made their own private solutions. I don't know exactly what ERSC are going to offer but it's surely going to be in that space and also probably not going to be super relevant to private individuals.
If the worst thing you can say about a git hosting provider is that the performance of their blog is worse than the performance of their git servers, I think they're probably doing an okay job.
While this is true, we do care about performance tremendously, and the animation not having good performance cuts against that, so I think it's a very fair criticism. Paying attention to details matters.
Thanks, I'm a Windows user and use Chrome myself, and on my machine it works great, but it's a pretty beefy box. I mentioned this downthread to someone else, but I've filed a bug internally and we'll make sure that it's better optimized. Thank you for the report, it's truly helpful.
> 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 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.
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?
If you ask "apart from better UX, what's the advantage of this thing?", you might as well ask "why would I buy an iPhone when my Nokia can do more things?".
While this is true and I agree with you, to be clear we do way more than just a nice UX. There is a lot of deep technical work going on here. If anything the UX isn’t the selling point, we are an infrastructure company at heart.
Absolutely everything in this industry is just a façade over the underlying ability to pass current between the source and the drain of transistors. "Just a better way to do ______" is the entire software sector.
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.
How is this undo different than Git's reflog? Genuinely curious, while I have heard of jj I haven't yet tried it (I read it couldn't handle git submodules, which would have made it dead in the water for my dayjob, that seems to still be the case).
1. Reflog is very ref specific that is it tracks head. JJ has op and evo logs that do that + a bunch more they track everything about the repo every possible action. It's hard to explain with going into technical depth but you can read up on it.
2. Yeah submodules aren't supported but since you can use jj in a git repo you can commit git stuff via git like submodules and then enjoy the world of jj. Since submodule interactions should be rare imho. I use it for a bunch of projects with submodules.
reflog can't quite catch every change that might happen because not everything is stored directly as a ref (ie a "head" that git tracks, like a branch pointer).
For instance, if you are interactively using `git bisect` and you mark commits as good or bad, and you accidentally mark a commit incorrectly, you have to do something like:
The reflog can't really capture this kind of thing, hence why you have a bisect log -- now a wholly separate concept that exists independently of the reflog.[1]
Another example is when you do something like screw up an interactive rebase. Let's say you rebase 20 commits and then you get a conflict on commit 8. You fix the file conflicts, and continue. You accidentally solve the merge incorrectly, continue and get another conflict -- but only realize your mistake after you start solving it. The reflog can't save you here. You have to completely abandon the rebase and start over. (This specific example might be handled better these days).
I think the biggest thing about `jj undo` is that it works everywhere. You can undo rebases, merges, conflict resolutions, copies, deletions, whatever. The secret behind it all is that internally, jj is architected in a way where implementing a feature looks like you are working with a transactional database. You actually have `begin_transaction()` and `commit()` methods in the codebase that will make changes to the commit graph visible in an atomic way. When a command like `jj rebase` happens, all of the changes it makes are inside a transaction and committed at once. Every operation in the repo is a transaction, and it all goes into a log, which records the effects of a transaction -- very much like a database system!
So "undo" just means "undo the effects recorded in a transaction" and that is about all. And so it works for everything! And this design is very easy to intuitively understand and program against, as a maintainer, along with our other high level internal APIs. Any developer can easily write code that Just Does The Right Thing and the user can undo it and it's no big deal. When I develop and work on Jujutsu myself -- like I'm actively developing new features or prototyping ideas -- I almost always _use my own jj repository_ as a test repo while testing my builds.
In contrast, Git does not have one unified "transactional" layer for things like this. But not all is lost, there has been work on 'git undo' and it was implemented by... Someone who is now a Jujutsu maintainer[2]. :)
[1] Technically we do not yet have "step by step" bisect with good/bad yet (only "automatic" bisect that is one-shot), so that is something Git can do we can't do at all right now, but bear with me. :')
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?
It’s fundamentally no different than doing the same resolution in git.
The main advantages are that you can do the changes piecemeal, in any order, at any time, and by jumping around in the commit history however you need or want to.
Sometimes the best way to solve a conflict is by changing something before the conflict, or by moving pieces from one commit to another. Git doesn’t allow this, you can only do: fully fix commit 1, fully fix commit 2, fully fix commit 3, and so on.
No worries, it's still just another commit w/ conflict. If you want, solve those conflicts later.
Why is git's "forced conflict resolution" better, assuming the same workflow (local change+sync upstream) would produce the same # of conflicted commits?
git doesn't force conflict resolution earlier. It forces conflict resolution the moment you pull changes from upstream. jj allows you to go back to the first conflicting commit and then fix things there. That first conflicting commit is most likely a lot more similar to the upstream code than your newest commit and therefore it is easier to fix.
jj itself doesn't have a native ‘push’. `jj git push` and `jj piper upload`¹ operate on external systems that don't necessarily support undoing arbitrary operations. Pure speculation, but if I were ESRC I'd make my backend handle it (subject to enterprise audit policies).
You can undo a push, yes. It undoes the local state of the remote branches after the push operation. ie: branch@origin will point at the commit it did before the push action. It doesn't actually update the branch on the remote. That would require another push operation.
Jujutsu is built on top of Git, so it can benefit tools in the same ecosystem (forges, CIs, code quality tools, IDEs, plugins, etc).
I have only played a little with jj and hg, but I felt that jj has a more modern UX, learning from years of Git existence (and even influencing Git, like the new `git history` command [1]). On the other hand, hg was created in the same month as Git, both trying to improve the experience of the VCSs available at the time (april 2005).
Git already won through Github, the Linux kernel, and other important projects. Even if you like Mercurial's syntax better (I do) and wish it won (I do), that battle was over many years ago.
jj's data store is git. You can use jj while other people on your project just use git. There's no migration of data or history. You can use Github and all of the various git tooling that exists today.
As such, the initial cost of switching to jj is zero for individuals, teams, or projects. That's huge.
jj's ergonomics are significantly nicer. Fewer ways to shoot yourself in the foot, much better merge resolution, etc.
It is possible to move one step further: use own store, speak git protocol. In the end, it is about the commit-tree-blob model. I think, the main headwind is the broad decay of interest in computer science topics.
Where can I read on jj merge resolution strategies? LLM links to Arch Linux man page and other random stuff.
You can speak the git protocol over the network only, but one advantage of using the same storage on disk as Git and exposing it in the same way (in a manner that keeps jj/git in sync) is that git-based tools still work. So, people still get diff markers in the gutter of their editor buffers, random scripts that do `git rev-parse` or whatnot still work out of the box, etc. This makes the experience more seamless and imposes less friction on non JJ users, eg you do not have to write a patch and add a special case for JJ because `git rev-parse` failed to run and then ask pretty please to merge it (and then keep doing that forever as you are the only user).
It doesn't sound like much, but before I started contributing to Jujutsu I was a user of https://sapling-scm.com/ -- Sapling is fantastic. It stores data on disk in git format, but back then it was not exposed to the user by default -- the .git directory is hidden away. It actually ended up causing a lot of friction that random `git` commands would not work, or tools had other various git-based behaviors. These days, sapling has a "dotgit" mode (partially inspired by jj I assume) that puts the .git directory in the root dir, so `git` commands still work.
Beyond that though, speaking Git over the network only has other complications on the client side. In particular Git clients and servers negotiate what objects each side has (given what the client requests), and from that negotiation derives a list of needed objects to give the client, and then sends a packfile for it. This is all relatively expensive to do on demand, actually, so it would make the interactivity for network operations much worse if you need to wholly translate your storage into packed objects, etc. And doing it efficiently would require you keeping a cache around that is basically a git database anyway, so you might as well just go ahead and use it. Not the end of the world in terms of downsides, but a trade-off that adds some baggage.
Using a different data store breaks compatibility and dramatically increases the friction to switching to it. jj's superpower is that my usage of it is invisible. Right now I'm working on Github projects in jj where none of the other contributors are. Nothing about my usage of jj requires them to change anything they do.
Mercurial is too slow. Even with chg common commands like `hg status` may take hundreds of milliseconds. JJ is fast. Internally `jj log` taking more than 500ms is tracked as bugs.
Others have answered about traction. As a one-time Mercurial user, I think the single most significant addition is first-class conflicts, so that dealing with them doesn't stop the world but can be deferred until I'm working on a particular conflicted change. (That also eliminates the need to ‘evolve’.) Easy undo is also nice.
My relatively ignorant take is that it's pretty similar to Mercurial, except that it's compatible with git repos, which is also the answer to why it might get more traction. At least from my standpoint, it also doesn't need to get traction, because I freely use it with git repos without any of my coworkers needing to use it as well (although they might! I have no idea, just like they probably don't know I use it)
Badass!!! Congrats. I love JJ’s mental model. Its so much less opionated and lets me do what I want. Want to make 5 versions of the same commit? Easy. Need to push out a change asap without having to pre create a branch, stash your changes, yadayada. Jj just adapts.
Once you start thinking in jj it becomes frustrating having think back to use GitHub as a code repo.
I think it's closer to: develop something similar to Google's Piper as (hopefully!) an open source project and sell this to enterprise, similar to Perforce's business model but with the benefit of an excellent and well received frontend tool.
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.
That idea about keeping maintainer balance is pretty neat, interesting to see this kind of diligence in maintainership in the same project where legal ownership belongs to a single company, Google, via the Contributor License Agreement. My interest in jj cooled off a lot after seeing that, even though I realize in practice it's pretty unlikely to be of consequence - I just don't need even that kind of low probability Sword of Damocles hanging over my VCS, forks and drama in case Google decides to mess things up. (Good to see that the Readme has been changed to say it's not a Google-supported project btw, less misleading than the old claim that it's not a Google project at all.)
We (East River Source Control) don't run Jujutsu, it does not "belong" to us -- it is a community project! Nothing has or is changed. Most of the contributors have nothing to do with us/Google/whoever. We get tons of great contributions from highly experienced and talented individuals. It's healthy, check it out: https://github.com/jj-vcs/jj/commits/main/
Most of the maintainer stuff is also overhyped in a way (OSS maintainer-heads know this). The maintainer group is largely structured to just keep things moving; not really a privilege but a responsibility -- making sure things get merged, doing technical reviews, ensure builds are unstuck, and hitting the green approval button. Our own community members also do code review, find bugs, triage things, answer questions, design features, help get users unstuck, etc. We are very much not alone, and I have great confidence in the constitution and strength of the community itself as someone who has been around the block a few times.
This is going to sound silly and "guy approves of himself" adjacent, but I've been doing OSS maintainer stuff for like 2 decades at this point, and jj is truly a gem as a project. It is vibrant, and the community is generally speaking insanely talented (huge number of git powerusers), and we have a weird dogfood advantage where people use the tool to contribute right back to it. Martin did an awesome job setting the tone of the project just through his behavior before many of us joined years ago. He's a naturally good project lead.
As I said elsewhere: I work for ERSC and I am a Jujutsu maintainer. This is just me speaking candidly on my own behalf.
I tried jujutsu for a while and it’s nice if you’re the kind of person who lives in the commits. But it became a bit of a pain to manually move the branch name around all the time, and I spend a lot more time moving forward on a few branches than I do trying to figure out histories so I went back to git.
FWIW, most of the time I don’t even bother naming my branches. ‘jj git push -C` even handles naming for me when I want to make a PR, but that’s mostly the only time I bother.
When I do need to advance a branch name, `jj bookmark advance` is easy enough. And it works great with the model that `jj git push` pushes all out-of-sync branches. In this model, advancing a bookmark is the reliable signal that I’m ready to share work, not simply “having authored a commit”.
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.
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.
Thanks! I don't have Opera installed on my Win11 machine, but I tried it in Edge and it's barely using anything, but I realize that I have something beefier than a shared GPU on it.
I've filed a bug internally and we'll make sure to take a look. We don't use these animations in the product, only the company site, so this is the first time it's hitting a broader audience. I appreciate the report and sorry about that!
The things I am most interested in right now are jj and llms. And the intersection between the two. I'm thinking a lot these days about how agentic development is changing our industry, with source control being one part of that.
We tested it in mobile, but several people pointed out that we have more performance work to do to make sure that the animation is fast on lower-end hardware. I don't know what phone you're using, but we'll get it fixed regardless.
One more data point--I'm using Firefox on an M1 Mac mini (MacOS 15.7.7), and this web site destroys the responsiveness of this system in a way I have literally never seen before (4+ years) from anything, web site or otherwise.
I opened up Activity Monitor and CPU use looked normal but it showed the GPU was pegged at 100% as long as that page was open.
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.
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."
seems to respect reduce motion just fine! the animation, while extremely lovely, also does seem to be quite taxing on my GPU (~60% usage on M1 Max with Zen/Firefox, on a 1440p widescreen, which is admittedly quite a lot of space to render animation)
love the website though, i hope i one day will be able to make something that elegant!
Can't live without JJ, but it does not scale yet: waiting sparse, blobless, treeless support
Working with Martin has been a real pleasure, and we'll have some more stuff to talk about very soon!
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?
There is active work in this area, yes! https://github.com/jj-vcs/jj/issues/3386 is the bug tracking the feature request, and there have been some recent PRs working on implementing this, see here for one example: https://github.com/jj-vcs/jj/pull/9864
Do you happen to have or know of any good open source projects on any public platform like GitHub, gitlab or Codeberg, that uses Jujutsu/jj?
It's hard to tell since any given dev can just use jj locally, if they want to, while everyone else uses git.
Technically, you can still tell actually - jj writes a "change-id xyz..." in the git commit object header, which remains there as it's pushed around. It's just typically not made visible by regular things. (I wonder what other random garbage has been hidden in git commit headers that noone has seen)
Checkout Gisia https://github.com/gisiahq/gisia
If I remember correctly, Mitchell Hashimoto uses it for Ghostty (probably under the git backend).
jj uses git as a backend. None of those need to "use" jj. You can use jj in an existing git repo, with your git wielding friends.
excited for what you guys would be coming up with ;)
btw, did Martin leave google?
Thanks!
Martin left Google for this, yes.
Wasn't it partially owned by Google? Or are they just a contributer now?
I like to compare Google and jj to Mozilla and Rust: Google employed Martin and some other maintainers, but it's always been an OSS project under the Apache 2.0 license.
That being said, there's a few things that lead to this perception: the first is that it used to be under Google's GitHub account, but is now under its own org. The second is that contributing to jj does require signing Google's CLA. That is something that is desired to change, but that's up to Google. Due to the license, the community could fork it, and still have the rights to use the code, but that would be pretty aggressive, and so everyone involved would rather work together on this than do so. The move to its own GitHub org was one example of movement in that direction, but I'm not aware of an actual timeline to remove the CLA just yet. The project will figure it out over time.
(I have a commit bit but am not a jj maintainer, so the above is my own impression from being involved in the community for the past few years.)
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.
I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint (lots of inconsistent naming of things and somewhat leaky abstractions), and that Mercurial faced an uphill battle in large part because it lacked compatibility with what people were already using. I haven't used Mercurial, but from what I've heard quite a lot of how jj does things is similar to Mercurial, just in a way that's compatible with git. I haven't used git directly for over a year in favor of using jj despite exclusively using git repositories, and no one I've worked with has even needed to be aware.
> I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint
Not really. I remember my early years with git and the favt was that I never needed more than clone, add, commit, pull and push. While I’ve done some mistakes that got ne to learn more, especially with creating branches and undoing. I’ve never needed a lot, even when I started using GUI which exposed more concepts.
Why? Because I have no understanding of version management and how it’s useful in a dev workflow/release process. I was just using it for checking in work.
Since then, I’ve read the “Pro Git” book, learned how devs and teams handle versioning and devel a good understanding of how git can help me in my coding process and general software development. And it’s very good at what it does.
I honestly kind of think your experience is in favor of the GP’s assessment.
It doesn't require that everyone switch at the same time, unlike other VCSs.
I like the idea of jujutsu, but I must not operate at a scale where its "killer features" would truly shine. Git hardly ever gets in my way, I have never had to do complex octopus merges or anything like that. It's usually: feature branch, implement, merge, and occasionally fix a merge conflict. JJ seems like it's more for people that like to have tons of active branches that they are constantly switching between whereas I usually only work on 1 thing at a time. I've never thought to myself "git is so frustrating I wish there were something better" because I only use the same 5 commands over and over every day and they never get in my way. Not to mention jj has its own share of esoteric syntax with all the "@--+::" business and I'd have to re-wire my brain to remember those symbols instead of `ref~N`, etc.
I was a skeptic until a few months ago. It’s my daily driver now. I’ve got sizable amount of people committing to the same repo, many are not skilled with git. So I deal with weird crazy “how did you ever get the repo into this state” issues not infrequently.
JJ is just so low friction. The seamless and painless shuffling of commits, working up and down the commit chain without explicit rebasing, unchanging change-ids. The min identifiers in change-ids being highlighted. Being able to make commits and worry about the message later. Snapshots of changes while you are working serving as a tool agnostic undo.
Painless and sensible cli args that are vastly more consistent than git.
Superior conflict handling.
You can “jj undo” anything and it works perfectly.
It’s fabulous.
> "@--+::"
I have no idea what that means and I’ve never had to type anything remotely like it.
The rev specification language is pretty elaborate but you don’t need to know it.
Same experience. At first I really didn’t get it and now I could never go back. The ease of rebasing, renaming, reordering, splitting, etc. Has drastically changed the way I work. My PRs are undoubtably much better now, and I am never afraid of messing up thanks to jj undo and the op log in general
A few advantages for me, even for the same 5 commands I use over and over:
- undo
- shuffling commits around with squash, split, and rebase is much better than git’s interactive rebase
- make commits without having to come up with a branch name (I might make three versions of the same change in parallel to see how they compare)
I see git is working on adding some of this under the history command. The revset language is really not esoteric: @ is head, @—- is two behind head. That’s about it.
Part of it is that the sorts of shuffling I used to avoid because they were a pain in git (so I didn’t feel I needed them improved) are so easy in jj that I do them all the time.
I disagree.
Similar to you, 95% of the time I do the simple use case that I've memorized. The problem is that even after a decade of using Git, when I get into those 5% where something goes wrong, I have no idea how to actually solve it. None of it makes any sense in my head, and I have to search for a bunch of magical commands to run, or nuke things to get back to a good state.
With JJ, it just makes sense. It's intuitive and clear. I have been able to recover without any help. Just the undo alone is basically a life saver. Rebasing and merge conflict resolution is so much simpler.
Yes I probably won't use it to its full potential, but still, the little I do use makes 10x more sense than Git ever did.
I don’t know about you, but if you ever run git commit --amend, git rebase -i, git reset, git reset --hard, git stash, git add ., git push --force-with-lease, then these are all workflows that jujutsu makes easier and less error-prone.
if you make commits, then you are at the scale where its killer features would shine. In other words, even the most basic git usage is made easier with jj.
If you care to learn more, there's tons of posts on hn and the broader web, so I won't bother sharing any links. I will say, though, that you should use it with jjui, which is a tremendous TUI for jj - you don't even really need to learn any of the actual jj syntax because it just handles it all for you.
jjui is the killer feature for me
https://github.com/idursun/jjui
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.
Edit: Thank you to everyone who replied. The enterprise/teams infrastructure angle makes sense.
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.
All but one of my employers have used either Github or Gitlab, and at every one of them there were a litany of complaints about whichever one we were using. It's kind of surprising to me that someone might not immediately recognize that there's certainly potential there for something better suited to what companies are actually looking for. Obviously there's no guarantee of success, and maybe the problem is too hard to solve, but that's pretty much how any company starts out!
I think it’s partly about how many steps back you take. Take another step back and you might see a new option that will in ten years be added to your list of options lots of people use and have plenty of complaints about.
I’m not saying not to try or that there’s no value in turning the wheel once more. But I used to be excited about these kinds of things and now I’m not because I’ve seen the cycle a few times now.
I’m very excited to see the great work ERSC has/will do. When thinking about where Git lags today, I’ve come up with three categories: UX features and custom data not natively understood by the Git CLI, a stock git-http-backend that doesn’t scale well to moderate monorepo size in server compute / storage, and a wire protocol that isn’t as flexible as it could be for special requests.
But there are so many hooks into the Git workflow today, and I’m struggling to find a “user story” that would not be met by custom Git tooling. UX could be added to Git objects à la Gerrit with custom CLIs, custom Gitoxide ODB and (eventually) ref storage backends can help the server scale, and things like promisor remotes and partial clones can keep things smaller on the client side.
I’m curious what ERSC is able to share publicly about where the scaling fails with the Git specification? Is it the wire format, or the relative speed of upstreaming new things to Git? Or is the side-channel approach for storing rich data in Git objects insufficient in some way?
P.S. I wrote a blog post[1] about this a bit ago. I’m sure I’m missing something. Since I wrote it, I’ve wondered if the lack of deferred conflicts in-tree would be a scaling limiter.
[1] https://jdc.pub/posts/git-jj
Thanks!
Yes, it's important to realize that git is multiple things: the on-disk repo format, the CLI, and the wire protocol. Each has their own challenges, just like any project, but they can be tackled independently. But at the end of the day, there just are fundamental limits to the way that git does things that make total sense in the context Linus developed git for, but just do not in other ones. Some of those are performance related, but some of those are things like how the kernel is an open source project, and so per-directory ACLs are something that git wouldn't ever bother supporting, but are valuable for companies. We'll be talking about these things in the future, so I'm just going to be hand-wavy about it right now. But we do think that git is a really great system that has served us all well for 20 years, but just like how git displaced systems before it due to significantly re-thinking the details, for some users, making meaningful improvements over git will also require a similar significant re-think. That's just the way of technological development.
As someone trying to compete in this space: will ERSC make the change/commit their unit of code review? It's one of the pet peeves I have with GitHub et al.
Yes. Stacked diffs are table stakes.
Well, stacking is one thing, doing it well is another (see github) ;)
But that's good to hear.
Are you guys hiring? (Software Engineer that writes in Rust.)
We are not actively hiring at the moment, but will be in the future for sure.
Post to the HN Who’s Hiring threads when you do :D
so most of my guesses about ersc are true, except it is only for enterprise? or do individuals also get access eventually?
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.
I think it's unlikely that individuals will need their product, unless you happen to have a 100 million line monorepo. (At least based on what it sounds like they're targeting.)
Normal Git/JJ is fine for most people, and most open source projects. It's just when you get to the scale of commercial software companies (100+ employees) you run into the classic monorepo/submodule problem.
Monorepos are currently the best solution - they make testing tractable, you can do cross-project changes, Git's support for them isn't buggy as hell. But they have obvious downsides - performance is the big one, but also integration with open source projects, permission control, etc.
So there's this big problem space that really only matters to companies where as far as I know there are currently no good open source or even commercial solutions. The only people that have (maybe) solved it are the mega-corps like Facebook and Google who have made their own private solutions. I don't know exactly what ERSC are going to offer but it's surely going to be in that space and also probably not going to be super relevant to private individuals.
The enterprise sounds accurate.
You mention performance issues with Git, but there are performance issues with this blog post.
If the worst thing you can say about a git hosting provider is that the performance of their blog is worse than the performance of their git servers, I think they're probably doing an okay job.
While this is true, we do care about performance tremendously, and the animation not having good performance cuts against that, so I think it's a very fair criticism. Paying attention to details matters.
What is your browser/OS combo? I am assuming it's the animation, we tested it thoroughly but there can always be bugs. Thank you for bringing it up!
Windows, Chrome, fans spin, recommend ai review
Thanks, I'm a Windows user and use Chrome myself, and on my machine it works great, but it's a pretty beefy box. I mentioned this downthread to someone else, but I've filed a bug internally and we'll make sure that it's better optimized. Thank you for the report, it's truly helpful.
Firefox on Linux
> 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 :- ))
And you can deal with them in any order, bit by bit, or by adjusting things in earlier commits. I no longer fear rebase conflicts.
"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 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.
Maybe like some kind of https://jjhub.com :-)
> jujutsu works with git.
Just like TypeScript with JS, QUIC with UDP, GraphQL with HTTP, Android with Linux, and so on
> git can do everything jujutsu can do (otherwise, jujutsu couldn't work with git)
Replace "jujutsu"/"git" by "typescript"/"js", "quic/udp", etc and you'll understand.
> git can do everything jujutsu can do (otherwise, jujutsu couldn't work with git).
assembly can do everything [insert high level language] can do. why not just write everything in that?
this is a very legit question. my few cents:
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?
Assembly can do everything Python/Java/Rust can do yet you might not wanna code in assembly if you don’t have to.
If you ask "apart from better UX, what's the advantage of this thing?", you might as well ask "why would I buy an iPhone when my Nokia can do more things?".
While this is true and I agree with you, to be clear we do way more than just a nice UX. There is a lot of deep technical work going on here. If anything the UX isn’t the selling point, we are an infrastructure company at heart.
I think the original question (and my answer) were more about jj vs git than about you guys, but I may have read it wrong.
Oops you’re not wrong, there’s just a lot of comments and it’s hard to keep threads straight, my bad :)
Absolutely everything in this industry is just a façade over the underlying ability to pass current between the source and the drain of transistors. "Just a better way to do ______" is the entire software sector.
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.
How is this undo different than Git's reflog? Genuinely curious, while I have heard of jj I haven't yet tried it (I read it couldn't handle git submodules, which would have made it dead in the water for my dayjob, that seems to still be the case).
1. Reflog is very ref specific that is it tracks head. JJ has op and evo logs that do that + a bunch more they track everything about the repo every possible action. It's hard to explain with going into technical depth but you can read up on it.
2. Yeah submodules aren't supported but since you can use jj in a git repo you can commit git stuff via git like submodules and then enjoy the world of jj. Since submodule interactions should be rare imho. I use it for a bunch of projects with submodules.
reflog can't quite catch every change that might happen because not everything is stored directly as a ref (ie a "head" that git tracks, like a branch pointer).
For instance, if you are interactively using `git bisect` and you mark commits as good or bad, and you accidentally mark a commit incorrectly, you have to do something like:
The reflog can't really capture this kind of thing, hence why you have a bisect log -- now a wholly separate concept that exists independently of the reflog.[1]Another example is when you do something like screw up an interactive rebase. Let's say you rebase 20 commits and then you get a conflict on commit 8. You fix the file conflicts, and continue. You accidentally solve the merge incorrectly, continue and get another conflict -- but only realize your mistake after you start solving it. The reflog can't save you here. You have to completely abandon the rebase and start over. (This specific example might be handled better these days).
I think the biggest thing about `jj undo` is that it works everywhere. You can undo rebases, merges, conflict resolutions, copies, deletions, whatever. The secret behind it all is that internally, jj is architected in a way where implementing a feature looks like you are working with a transactional database. You actually have `begin_transaction()` and `commit()` methods in the codebase that will make changes to the commit graph visible in an atomic way. When a command like `jj rebase` happens, all of the changes it makes are inside a transaction and committed at once. Every operation in the repo is a transaction, and it all goes into a log, which records the effects of a transaction -- very much like a database system!
So "undo" just means "undo the effects recorded in a transaction" and that is about all. And so it works for everything! And this design is very easy to intuitively understand and program against, as a maintainer, along with our other high level internal APIs. Any developer can easily write code that Just Does The Right Thing and the user can undo it and it's no big deal. When I develop and work on Jujutsu myself -- like I'm actively developing new features or prototyping ideas -- I almost always _use my own jj repository_ as a test repo while testing my builds.
In contrast, Git does not have one unified "transactional" layer for things like this. But not all is lost, there has been work on 'git undo' and it was implemented by... Someone who is now a Jujutsu maintainer[2]. :)
[1] Technically we do not yet have "step by step" bisect with good/bad yet (only "automatic" bisect that is one-shot), so that is something Git can do we can't do at all right now, but bear with me. :')
[2] https://blog.waleedkhan.name/git-undo/
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?
It’s fundamentally no different than doing the same resolution in git.
The main advantages are that you can do the changes piecemeal, in any order, at any time, and by jumping around in the commit history however you need or want to.
Sometimes the best way to solve a conflict is by changing something before the conflict, or by moving pieces from one commit to another. Git doesn’t allow this, you can only do: fully fix commit 1, fully fix commit 2, fully fix commit 3, and so on.
No worries, it's still just another commit w/ conflict. If you want, solve those conflicts later.
Why is git's "forced conflict resolution" better, assuming the same workflow (local change+sync upstream) would produce the same # of conflicted commits?
git doesn't force conflict resolution earlier. It forces conflict resolution the moment you pull changes from upstream. jj allows you to go back to the first conflicting commit and then fix things there. That first conflicting commit is most likely a lot more similar to the upstream code than your newest commit and therefore it is easier to fix.
Are you saying push + undo = unpush?
jj itself doesn't have a native ‘push’. `jj git push` and `jj piper upload`¹ operate on external systems that don't necessarily support undoing arbitrary operations. Pure speculation, but if I were ESRC I'd make my backend handle it (subject to enterprise audit policies).
¹ https://drive.google.com/file/d/1dVzug1lHoOxdbFu8gcCJCu-G_uV...
Reminds me of the git-svn bridge.
Points of no return.
You can undo a push, yes. It undoes the local state of the remote branches after the push operation. ie: branch@origin will point at the commit it did before the push action. It doesn't actually update the branch on the remote. That would require another push operation.
AFAIKT it will revert the local state to "pending push".
Jujutsu is a better smarter git. It's a great convergence of better UX, plus more expressive, plus easier to use.
If you haven't tried jj yet, take it for a spin and see how you like it.
How does it compare to Mercurial? And why would it get more traction than Mercurial?
Jujutsu is built on top of Git, so it can benefit tools in the same ecosystem (forges, CIs, code quality tools, IDEs, plugins, etc).
I have only played a little with jj and hg, but I felt that jj has a more modern UX, learning from years of Git existence (and even influencing Git, like the new `git history` command [1]). On the other hand, hg was created in the same month as Git, both trying to improve the experience of the VCSs available at the time (april 2005).
[1] https://lore.kernel.org/git/20250819-b4-pks-history-builtin-...
Git already won through Github, the Linux kernel, and other important projects. Even if you like Mercurial's syntax better (I do) and wish it won (I do), that battle was over many years ago.
jj's data store is git. You can use jj while other people on your project just use git. There's no migration of data or history. You can use Github and all of the various git tooling that exists today.
As such, the initial cost of switching to jj is zero for individuals, teams, or projects. That's huge.
jj's ergonomics are significantly nicer. Fewer ways to shoot yourself in the foot, much better merge resolution, etc.
It is possible to move one step further: use own store, speak git protocol. In the end, it is about the commit-tree-blob model. I think, the main headwind is the broad decay of interest in computer science topics.
Where can I read on jj merge resolution strategies? LLM links to Arch Linux man page and other random stuff.
You can speak the git protocol over the network only, but one advantage of using the same storage on disk as Git and exposing it in the same way (in a manner that keeps jj/git in sync) is that git-based tools still work. So, people still get diff markers in the gutter of their editor buffers, random scripts that do `git rev-parse` or whatnot still work out of the box, etc. This makes the experience more seamless and imposes less friction on non JJ users, eg you do not have to write a patch and add a special case for JJ because `git rev-parse` failed to run and then ask pretty please to merge it (and then keep doing that forever as you are the only user).
It doesn't sound like much, but before I started contributing to Jujutsu I was a user of https://sapling-scm.com/ -- Sapling is fantastic. It stores data on disk in git format, but back then it was not exposed to the user by default -- the .git directory is hidden away. It actually ended up causing a lot of friction that random `git` commands would not work, or tools had other various git-based behaviors. These days, sapling has a "dotgit" mode (partially inspired by jj I assume) that puts the .git directory in the root dir, so `git` commands still work.
Beyond that though, speaking Git over the network only has other complications on the client side. In particular Git clients and servers negotiate what objects each side has (given what the client requests), and from that negotiation derives a list of needed objects to give the client, and then sends a packfile for it. This is all relatively expensive to do on demand, actually, so it would make the interactivity for network operations much worse if you need to wholly translate your storage into packed objects, etc. And doing it efficiently would require you keeping a cache around that is basically a git database anyway, so you might as well just go ahead and use it. Not the end of the world in terms of downsides, but a trade-off that adds some baggage.
Using a different data store breaks compatibility and dramatically increases the friction to switching to it. jj's superpower is that my usage of it is invisible. Right now I'm working on Github projects in jj where none of the other contributors are. Nothing about my usage of jj requires them to change anything they do.
The jj tutorial is useful: https://docs.jj-vcs.dev/latest/tutorial/
Mercurial is too slow. Even with chg common commands like `hg status` may take hundreds of milliseconds. JJ is fast. Internally `jj log` taking more than 500ms is tracked as bugs.
Others have answered about traction. As a one-time Mercurial user, I think the single most significant addition is first-class conflicts, so that dealing with them doesn't stop the world but can be deferred until I'm working on a particular conflicted change. (That also eliminates the need to ‘evolve’.) Easy undo is also nice.
> And why would it get more traction than Mercurial?
There's no network effect headwinds, it's interoperable with git (I assume most people using jj have an upstream repo that's on git).
My relatively ignorant take is that it's pretty similar to Mercurial, except that it's compatible with git repos, which is also the answer to why it might get more traction. At least from my standpoint, it also doesn't need to get traction, because I freely use it with git repos without any of my coworkers needing to use it as well (although they might! I have no idea, just like they probably don't know I use it)
Badass!!! Congrats. I love JJ’s mental model. Its so much less opionated and lets me do what I want. Want to make 5 versions of the same commit? Easy. Need to push out a change asap without having to pre create a branch, stash your changes, yadayada. Jj just adapts.
Once you start thinking in jj it becomes frustrating having think back to use GitHub as a code repo.
So if I understand correctly: ERSC is working on an alternative backend for jj other than git (and presumably providing related infrastructure)?
I think it's closer to: develop something similar to Google's Piper as (hopefully!) an open source project and sell this to enterprise, similar to Perforce's business model but with the benefit of an excellent and well received frontend tool.
No word about the future of Jujutsu, so I guess this is bad news for for jj users?
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.
That idea about keeping maintainer balance is pretty neat, interesting to see this kind of diligence in maintainership in the same project where legal ownership belongs to a single company, Google, via the Contributor License Agreement. My interest in jj cooled off a lot after seeing that, even though I realize in practice it's pretty unlikely to be of consequence - I just don't need even that kind of low probability Sword of Damocles hanging over my VCS, forks and drama in case Google decides to mess things up. (Good to see that the Readme has been changed to say it's not a Google-supported project btw, less misleading than the old claim that it's not a Google project at all.)
We (East River Source Control) don't run Jujutsu, it does not "belong" to us -- it is a community project! Nothing has or is changed. Most of the contributors have nothing to do with us/Google/whoever. We get tons of great contributions from highly experienced and talented individuals. It's healthy, check it out: https://github.com/jj-vcs/jj/commits/main/
Most of the maintainer stuff is also overhyped in a way (OSS maintainer-heads know this). The maintainer group is largely structured to just keep things moving; not really a privilege but a responsibility -- making sure things get merged, doing technical reviews, ensure builds are unstuck, and hitting the green approval button. Our own community members also do code review, find bugs, triage things, answer questions, design features, help get users unstuck, etc. We are very much not alone, and I have great confidence in the constitution and strength of the community itself as someone who has been around the block a few times.
This is going to sound silly and "guy approves of himself" adjacent, but I've been doing OSS maintainer stuff for like 2 decades at this point, and jj is truly a gem as a project. It is vibrant, and the community is generally speaking insanely talented (huge number of git powerusers), and we have a weird dogfood advantage where people use the tool to contribute right back to it. Martin did an awesome job setting the tone of the project just through his behavior before many of us joined years ago. He's a naturally good project lead.
As I said elsewhere: I work for ERSC and I am a Jujutsu maintainer. This is just me speaking candidly on my own behalf.
The article says this:
> von Zweigbergk will continue to be a core maintainer of JJ as an open source project under the Apache 2.0 license.
Isn't ERSC aiming to be for jj what GitHub was for git? In which case, this would be great news for jj.
I tried jujutsu for a while and it’s nice if you’re the kind of person who lives in the commits. But it became a bit of a pain to manually move the branch name around all the time, and I spend a lot more time moving forward on a few branches than I do trying to figure out histories so I went back to git.
FWIW, most of the time I don’t even bother naming my branches. ‘jj git push -C` even handles naming for me when I want to make a PR, but that’s mostly the only time I bother.
When I do need to advance a branch name, `jj bookmark advance` is easy enough. And it works great with the model that `jj git push` pushes all out-of-sync branches. In this model, advancing a bookmark is the reliable signal that I’m ready to share work, not simply “having authored a commit”.
Thought I saw that announcement on LinkedIn a few weeks back already!
Yes, he joined a few months ago, this is just getting it onto the site :)
what a lovely website
Thank you!
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.
Nick is great! Met him at the Recurse Center. Brilliant designer.
:octopus:!
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.
It's killing my GPU tho so can't look at it took long without my fans going to max.
What is your browser/OS combo? Thank you for bringing it up, we can only fix things that we hear about, so I appreciate knowing that something is off.
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.
Thanks! I don't have Opera installed on my Win11 machine, but I tried it in Edge and it's barely using anything, but I realize that I have something beefier than a shared GPU on it.
I've filed a bug internally and we'll make sure to take a look. We don't use these animations in the product, only the company site, so this is the first time it's hitting a broader audience. I appreciate the report and sorry about that!
Firefox on win11 here, scrolling the page is super choppy and it pegs my GPU at 100%.
Thanks!
There will be a lot more of it soon :D
Hire somebody who's got at least a modicum of understanding of (web) typography.
Small hint: A moving background layer makes reading supremely annoying, and for some people even (virtually) impossible.
I'll have it stop on non-homepages, it should also respect reduce-motion.
Any other reccs?
I'm way more interested in knowing what technologies Steve Klabnik is eyeing and planning to get involved with next.
I joined ERSC ten months ago!
The things I am most interested in right now are jj and llms. And the intersection between the two. I'm thinking a lot these days about how agentic development is changing our industry, with source control being one part of that.
Congrats (or what's the right word :- )) Martin and best wishes to you and ERSC,
Looking forward to using the VCS stuff you'll create :- )
At first I thought this post about martial arts…
This website has unbearable scroll performance on mobile.
Is it the animation at the top?
We tested it in mobile, but several people pointed out that we have more performance work to do to make sure that the animation is fast on lower-end hardware. I don't know what phone you're using, but we'll get it fixed regardless.
1 more data point - it's very slow on my desktop which has relatively high performance as well. Using Brave if that matters.
We're about to push a change that should improve this a bit, thanks for the reports!
One more data point--I'm using Firefox on an M1 Mac mini (MacOS 15.7.7), and this web site destroys the responsiveness of this system in a way I have literally never seen before (4+ years) from anything, web site or otherwise.
I opened up Activity Monitor and CPU use looked normal but it showed the GPU was pegged at 100% as long as that page was open.
"human ↔ machine collaboration" sounds rather creepy, to be honest.
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.
Big news. Congrats.
Thanks man :)
That’s amazing news. Can you share more about your tech stack? I suppose it’s mainly built with Rust?
We have a colopholon! https://ersc.io/colophon
Rust is the default language for all of our non-frontend web stuff, yes.
Is this new? The date says July 8, 2026.
Fixing, thank you!
(Martin joined back then, but we are posting about it today, so we should have the post date as today)
Can someone at ERSC please fix the issue preventing back/forward scroll gestures from working on the site?
Filed a bug, looking into it!
Edit: a fix is in review
What is ERSC?
I wrote a bit about this here: https://news.ycombinator.com/item?id=49526190
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.
This looks like excellent news.
am I in some alternate timeline where ISVs are able to make a profit selling version control systems?
We’ll find out!
New age of vendor lock-in?
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."
Yeah. I thought maybe someone from Gracie family joined something :)
(off topic) why the headache-inducing animated background? An annoyance for all, and an actual accessibility issue for some.
Not off topic!
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.
seems to respect reduce motion just fine! the animation, while extremely lovely, also does seem to be quite taxing on my GPU (~60% usage on M1 Max with Zen/Firefox, on a 1440p widescreen, which is admittedly quite a lot of space to render animation)
love the website though, i hope i one day will be able to make something that elegant!
What a pivot, from manga to software