I gave jj two honest tries. While first class conflicts is a cool idea, in practice I deal with staging/committing 30x more than conflict resolution, and coming from magit, using jj’s hunk split & select felt like being thrown into stone age. Plus I rebase a lot and get a lot of jj’s benefits from magit’s various rebase shortcuts already, IIRC first class conflicts was the only truly novel thing I didn’t have. For people like me who stage/commit often and judiciously I don’t think jj will beat magit until its hunk selection UX comes close.
In jj you aren’t supposed to be even thinking about staging and committing, that’s the mental leap required to get what the fuss is about. Everything is a change and you bookmark a parent (or something further out) as the branch head into which you squash or advance the bookmark to a next ready change.
I’m curious what the magit hunk selection UX consists in. I couldn’t find any videos showing something substantially different from the one built into jj — the videos I found were meant as beginner intros.
I’ve never used magit but I used GitUp (https://gitup.co/) for years before jj. I don’t find the jj one super natural, but I feel like that’s mostly a matter of keyboard shortcuts — I need to see if they can be customized.
Seriously! I found that you can still use the git index as long as you don’t run any jj command that changes git_head, and then I made an alias to make a commit from staged changes (squash-index and split-index): https://github.com/CGamesPlay/dotfiles/blob/2484f6f7d0ab302e...
Exactly, me too. Things like `absorb` I'll take, but I don't want jj's opinionated approach to version control. And not only do I not want it for _me_, but I also don't want it for newbies because hiding too much of the underlying design, design issues, etc., seems counterproductive to me.
If you open your favorite git editor in a jj repo, everything you stage will become a new commit, everything you revert will… revert. I still use Sublime Merge rather frequently.
I have Luddite feelings reading about alternatives to Git.
As an industry we have soooo many languages, frameworks, tools, distros etc. It's like we are pre metric system or standardization on screw thread sizing.
I am really happy that at least for VCS, we have a nearly universal solution in Git, except for the big tech folks.
Sure, jj might solve some issues, but once it gets serious traction, all the tooling that works with e.g. repo analysis will need to start supporting git and jj. More docs need to be created, junior developers will need to learn both systems (as git is not going anywhere).
Given all the downstream effects, I do not think introducing another VCS is a net positive.
In my case, the shoddiness and thoughtlessness of Git's user interface pisses me off so much that I just want it to be replaced. A good tool similar to Git may even explain Git's concepts better than Git or its documentation that likes to discuss "some tree-ish refs".
I started using git when my employer still used svn. This was possible because `git-svn` was so good and it seamlessly allowed me to use branches to do development while still committing to svn's trunk. I think jj is trying to do something similar: jj-unaware tools work reasonably well in colocated jj repositories, and jj-unaware peers (CI tools, etc) work exactly as they did before.
I do agree that you can't really use jj without also knowing "a fair amount" about git, but notably you never need to use the git cli to be an effective contributor to a github project, which is basically the same as `git-svn` was back before git got popular.
More docs need to be created, junior developers will need to learn both systems (as git is not going anywhere).
Not true. Using jj is a choice made by a single developer. Nothing proprietary escapes from a jj clone of a git repo. Junior devs can use vanilla git if they really want to.
All the tooling that works with e.g. repo analysis will need to start supporting git and jj
Also not true, unless I misunderstand what you mean by repo analysis. Colocated jj repos are more or less supersets of git repos.
Git absolutely is a productivity drain and should be replaced, particularly as agentic coding takes over, as its footgun elements get magnified when you have a lot of agents working on one codebase at once. I dislike jj as move forward because I don't think it goes far enough for the amount of friction moving to it as an industry would entail.
The next generation of VCS should be atomic, with a proper database tracking atoms, and "plans" to construct repo states from atoms. A VCS built around these principles would eliminate branching issues (no branches, just atoms + plans), you could construct relationships from plan edit distances and timestamps without forcing developers to screw with a graph. This would also allow macros to run on plans and transform atoms, enable cleaner "diffs" and make it easy to swap in and out functionality from the atom database instead of having to hunt through the commit graph and create a patch.
The downside of an atomic design like this is you have to parse everything that goes into VCS to get benefits, but you can fallback to line based parsing for text files, and you can store pointers to blobs that aren't parseable. I think the tradeoff in terms of DX and features is worth it but getting people off git is going to be an epic lift.
Having used jj for the last year and a half, I hear you on the tooling issues. From IDEs, to plugins, to docs, to workflows, to LLMs, jj is not as well supported as git.
Despite that, it's still a net time-saver for me, and I suspect the same will be true for others. Git imposes constant overhead, mostly with its poor UI, but also by some of its unnecessary models (e.g., staging as a separate concept).
> I also don’t mean to imply that everyone at Google is using jj, but the contingent feels significant to me, given how hard it is to introduce a new VCS inside a company of that size.
I don't mean to imply that Google is fickle, but anything besides Google's perforce fork is deprecated every few years. We used to have a proper git wrapper, then mercurial+extensions, now jj is supposed to replace the mercurial thing, all in 7-ish years?
I tried jj, but I'm used to Sublime Merge. Doing version control in the command line was just too much repeated typing, as you keep losing information. In a GUI you always see the current state. You commit, it updates the display. A diff is a click away. Changing focus to type the commit message is a click away. No reason to ask the same questions again and again. Even with aliases like jjl for `jj log --limit 10` it felt too inefficient and annoying. Selecting individual hunks with the keyboard... I don't ever want to do that again. In SM it's a pleasure.
The git CLI might suck, but SM just doesn't. Looking forward to jj GUIs taking off. Or even better: jj getting integrated into SM.
I tried Jujutsu in the last day and was going through your tutorial. I really liked the experience and can see some potential. I also got the feeling that there is a missing puzzle piece. For example, do I get any benefit from the change id if I push to GitHub for PR review?
I guess you benefit from some of the good parts only with the Google internal Piper backend, at the moment. So I’m curious about the ideas and plans you have at ERSC.
But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in. The distributed nature of git somehow got lost with PRs or MRs in GitHub & Co.
Does it work with large binary files and not choke like git? Cause git may have won for webdev etc, but in some industries such as gamedev, Perforce is the king...
git is barely used at all because it can't handle binary files worth a damn(yes I know about the large file extension, no it isn't sufficient).
I joined the sapling/subversion company this year, but haven’t had the chance to use jj. But given its resemblance I must say sapling has been great. Much more intuitive than git, and I find commit stacks much easier to follow than branches. I do wonder how it will work without the level of support of Meta, since you won’t have the same commit stack review UI (basically a series of pull requests being reviewed at the same time). So something like what this author is working on is needed.
What I miss from the Perforce and Subversion days is committing directly to trunk in a team environment. Now everything revolves around PRs and lengthy code review. With direct commits to trunk, everyone was in a rush to get their commit in before someone else did, so they didn’t have to update and have conflicts. This made commits small, frequent, and usually well-scoped. What -sucked- was when you did need to do a large refactoring or other big change, then that was work best done on a weekend because branching and merging didn’t work very well.
Git’s model is right for PRs for open source projects where one day you could wind up with code from someone you don’t know and you need to take your time in review and possibly making further changes before merging. But as much as git’s a meaningful upgrade over Perforce and (especially) Subversion, branching and merging is not the right default model for normal team development.
PR's are a man made ritual that was never required by GIT. Just like we are all doing the Lean/Scrum or whatever dance. It does not change the development process, it's just a man made ritual for collaboration.
The branching model is nicer to work with than the revision based model from subversion though.
Since JJ has technically git compat, I think there's 2 things needed for it to take off
1. A good vscode extension (there's two so-so ones that I'm not sure are being updated)
2. LLM knowledge. I ask gpt-5 about doing something in jj the other day, it didn't even recognize it at first. When I reminded it it was a vcs it hallucinated half the commands. I ended up figuring it out myself from the docs
I've been enjoying the jujutsu kaisen VSCode extension, you just need to disable VSCode's built in git integration for each project where you use jj (although I'm planning to invert by disabling git globally and then only enable it for the few projects where I don't use jj)
One thing I've wanted is the ability to group commits into a mega commit. So the history of little changes remains, but as you are scrolling you don't see all of them.
I’ve been adopting jj for my personal projects for 1-2 months and have been very happy with it. One downside is if you move back to edit older revisions, it’s very easy to accidentally append something that was added to .gitignore in the meantime. I suppose it’s a relatively unique problem. Other than that I definitely like it, but my git knowledge accumulated over the years is still much larger than jj.
I guess I see what the author was trying to convey talking about Rust/Go at the start but I'll admit it confused the hell out of me when we got to Jj (horrible name IMHO but whatever).
Jj is a VCS, it was not at all clear (to me) until I got further and I was very confused as to why we were talking so much about source control (I thought Jj was a language since the article started by talking about Rust/Go).
Apparently Jj can work on/with git repos making it easier to adopt incrementally which is neat and the main point of this post is that the author is leaving Oxide to go work for a new company trying to to create the GitHub of Jj (my understanding at least).
I hope this helps someone else who might be confused like I was.
Thank you for the feedback! I talk about it so much I feel like regular readers of my blog will know this stuff already, but I also don't want to leave out important context for others.
The full name is Jujutsu, but I think "jj" did come first. "j" is nice because on QWERTY keyboards, not only is it on the home row, it is one of the two keys that has a little tactile marker (bump) on it.
So excited for this. I talked to the ERSC folks last year about joining but it was a little early for me. Still incredibly excited about what they're building and glad to see one of my favorite people joining the effort.
I think that the ability to collocate with fit is really the thing that makes even evaluating the use of jj feasible in many organizations. To consider pijul, it requires throwing away all of your forge setup, configuration, permissions, backup, disaster recovery, as well as updating every CI pipeline.
In a very real way, git won, and the inertia behind git is higher than it was for any VCS tool before it, and so just being better isn’t going to be enough, you’ll also need to interoperat.
I strongly suspect that its not feasible to colocate pijul and git. git and jj are based on snapshots, while pijul is based on patches. They have very different models.
Agree, the feature of commutative patches just seems obviously superior? Not sure why there's a critical mass to adopt jj over Pijul apart from jj's git backend.
[+] [-] oefrha|5 months ago|reply
[+] [-] baq|5 months ago|reply
[+] [-] dcre|5 months ago|reply
I’ve never used magit but I used GitUp (https://gitup.co/) for years before jj. I don’t find the jj one super natural, but I feel like that’s mostly a matter of keyboard shortcuts — I need to see if they can be customized.
[+] [-] CGamesPlay|5 months ago|reply
[+] [-] Balinares|5 months ago|reply
[+] [-] cryptonector|5 months ago|reply
Exactly, me too. Things like `absorb` I'll take, but I don't want jj's opinionated approach to version control. And not only do I not want it for _me_, but I also don't want it for newbies because hiding too much of the underlying design, design issues, etc., seems counterproductive to me.
[+] [-] pkulak|5 months ago|reply
[+] [-] ModernMech|5 months ago|reply
[+] [-] jtwaleson|5 months ago|reply
As an industry we have soooo many languages, frameworks, tools, distros etc. It's like we are pre metric system or standardization on screw thread sizing.
I am really happy that at least for VCS, we have a nearly universal solution in Git, except for the big tech folks.
Sure, jj might solve some issues, but once it gets serious traction, all the tooling that works with e.g. repo analysis will need to start supporting git and jj. More docs need to be created, junior developers will need to learn both systems (as git is not going anywhere).
Given all the downstream effects, I do not think introducing another VCS is a net positive.
[+] [-] ahartmetz|5 months ago|reply
[+] [-] CGamesPlay|5 months ago|reply
I do agree that you can't really use jj without also knowing "a fair amount" about git, but notably you never need to use the git cli to be an effective contributor to a github project, which is basically the same as `git-svn` was back before git got popular.
[+] [-] mpalmer|5 months ago|reply
[+] [-] fsw|5 months ago|reply
[+] [-] CuriouslyC|5 months ago|reply
The next generation of VCS should be atomic, with a proper database tracking atoms, and "plans" to construct repo states from atoms. A VCS built around these principles would eliminate branching issues (no branches, just atoms + plans), you could construct relationships from plan edit distances and timestamps without forcing developers to screw with a graph. This would also allow macros to run on plans and transform atoms, enable cleaner "diffs" and make it easy to swap in and out functionality from the atom database instead of having to hunt through the commit graph and create a patch.
The downside of an atomic design like this is you have to parse everything that goes into VCS to get benefits, but you can fallback to line based parsing for text files, and you can store pointers to blobs that aren't parseable. I think the tradeoff in terms of DX and features is worth it but getting people off git is going to be an epic lift.
[+] [-] miki123211|5 months ago|reply
I think this is JJ's biggest advantage. Whether you use it is independent of whether anybody on your team uses it.
[+] [-] KingMob|5 months ago|reply
Despite that, it's still a net time-saver for me, and I suspect the same will be true for others. Git imposes constant overhead, mostly with its poor UI, but also by some of its unnecessary models (e.g., staging as a separate concept).
[+] [-] weinzierl|5 months ago|reply
https://ersc.io/
[+] [-] j2kun|5 months ago|reply
I don't mean to imply that Google is fickle, but anything besides Google's perforce fork is deprecated every few years. We used to have a proper git wrapper, then mercurial+extensions, now jj is supposed to replace the mercurial thing, all in 7-ish years?
[+] [-] ahaferburg|5 months ago|reply
The git CLI might suck, but SM just doesn't. Looking forward to jj GUIs taking off. Or even better: jj getting integrated into SM.
[+] [-] mh9r|5 months ago|reply
I guess you benefit from some of the good parts only with the Google internal Piper backend, at the moment. So I’m curious about the ideas and plans you have at ERSC.
But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in. The distributed nature of git somehow got lost with PRs or MRs in GitHub & Co.
[+] [-] TinkersW|5 months ago|reply
[+] [-] jasonpeacock|5 months ago|reply
What does Perforce binary support have that Git LFS doesn’t?
AFAIK, the base issue that Perforce is already in use and it has enterprise support.
[+] [-] zamalek|5 months ago|reply
[+] [-] steveklabnik|5 months ago|reply
[+] [-] adamwk|5 months ago|reply
[+] [-] steveklabnik|5 months ago|reply
[+] [-] jonstewart|5 months ago|reply
Git’s model is right for PRs for open source projects where one day you could wind up with code from someone you don’t know and you need to take your time in review and possibly making further changes before merging. But as much as git’s a meaningful upgrade over Perforce and (especially) Subversion, branching and merging is not the right default model for normal team development.
[+] [-] ivolimmen|5 months ago|reply
[+] [-] cozzyd|5 months ago|reply
[+] [-] philipwhiuk|5 months ago|reply
I mean that's just toxic.
[+] [-] jmercouris|5 months ago|reply
[+] [-] steveklabnik|5 months ago|reply
[+] [-] archargelod|5 months ago|reply
Who upvotes this?
[+] [-] keyle|5 months ago|reply
[deleted]
[+] [-] gneray|5 months ago|reply
[+] [-] Bolwin|5 months ago|reply
1. A good vscode extension (there's two so-so ones that I'm not sure are being updated) 2. LLM knowledge. I ask gpt-5 about doing something in jj the other day, it didn't even recognize it at first. When I reminded it it was a vcs it hallucinated half the commands. I ended up figuring it out myself from the docs
[+] [-] jjmarr|5 months ago|reply
I only use it when I have a ton of minor PRs I want to work on simultaneously, otherwise I just do git worktrees.
I'm mainly in favour because my name is JJ and sharing my name with a widely-used source control tool might help my career.
[+] [-] Hasnep|5 months ago|reply
[+] [-] Pet_Ant|5 months ago|reply
[+] [-] davidkunz|5 months ago|reply
[+] [-] suralind|5 months ago|reply
I’m going to be slowly adopting it for work.
[+] [-] yomismoaqui|5 months ago|reply
[+] [-] joshstrange|5 months ago|reply
Jj is a VCS, it was not at all clear (to me) until I got further and I was very confused as to why we were talking so much about source control (I thought Jj was a language since the article started by talking about Rust/Go).
Apparently Jj can work on/with git repos making it easier to adopt incrementally which is neat and the main point of this post is that the author is leaving Oxide to go work for a new company trying to to create the GitHub of Jj (my understanding at least).
I hope this helps someone else who might be confused like I was.
[+] [-] steveklabnik|5 months ago|reply
I tried to help fix this in https://github.com/steveklabnik/steveklabnik.com/pull/125/fi..., thanks again!
[+] [-] sunshowers|5 months ago|reply
[+] [-] zephraph|5 months ago|reply
Steve, if you come to NYC hit me up!
[+] [-] baq|5 months ago|reply
[+] [-] mirashii|5 months ago|reply
In a very real way, git won, and the inertia behind git is higher than it was for any VCS tool before it, and so just being better isn’t going to be enough, you’ll also need to interoperat.
[+] [-] dagenix|5 months ago|reply
[+] [-] coastalpuma|5 months ago|reply