Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Funny how the threads are all about jj. Personally the move to a startup focused on version control, to me an obvious sinking ship, is more interesting. Not spectrum though.by pjjpo
- 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”.
by stouset - Hope ERSC is ready for their complex narrative structures. Jujutsu Kaisen's plot threads are mind-bending.by Wren_ops
- We have a multi-season arc already planned, with at least 4 unannounced characters
⋆˚.⋆⋆˚.⋆
by nickisnoble - 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.
- > Want to make 5 versions of the same commit? Easy
When do you need something like this?
by vaylian - No word about the future of Jujutsu, so I guess this is bad news for for jj users?by phi-go
- Isn't ERSC aiming to be for jj what GitHub was for git? In which case, this would be great news for jj.by mtlynch
- 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.
by Wyverald - 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.
by aseipp - 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.
by steveklabnik - So if I understand correctly: ERSC is working on an alternative backend for jj other than git (and presumably providing related infrastructure)?by ksymph
- 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.by yegle
- I pretty much only use jj now, and it was really good even just with the CLI. But adding jjui changed the story entirely. I now rarely use jj without just booting up jjui first.
It will be good to see what jj will look like with more funded dev work, but I'm always a little worried about financial incentives mixing with the tools I use for the long term. I guess the saving grace is that I don't really need more upgrades to jj or jjui as it stands. I'm pretty much content with the features and so I could just save this copy of the repo for future reference.
As far as large assets goes, I have my own VCS-ish system which I just integrate with jj, but it would be nice to see a non-git backend handle large assets better as well.
by ashkankiani - Same here. I keep jjui open the whole day, rarely reaching for jj itself. It really changed the way I work with repos.by ku1ik
- 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.
by jph - How does it compare to Mercurial? And why would it get more traction than Mercurial?by drsouth
- > If you haven't tried jj yet, take it for a spin and see how you like it.
And if your muscle memory doesn't allow an immediate transition, give yourself 2 weeks. That's how long it took for me at least.
Invest in custom tooling and helper scripts.
by VMG - 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.
by minraws - Are you saying push + undo = unpush?by sshine
- 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).by VorpalWay
- 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.
by yegle - 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.
by fallat - 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?".by stavros
- > 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?
by nchmy - > 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.
by lucasoshiro - 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.by jeffbee
- 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.
by rirze - "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.
by sbuttgereit