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.
> 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.
Does not sound any easier or more intuitive than git.
> For people like me who stage/commit often and judiciously
Focus on judiciously: mostly (functionally) atomic commits that are not every tiny change, not largely meaningless time-based snapshots, not Gerrit-style single commits for entire features, etc. I’m well aware of the mental leap you’re talking about, it’s neither hard to understand nor the liberation you might think it is. To achieve what we want to achieve we either need to be able to split, or “commit” with such atomicity that more time is wasted come squash time.* If you don’t get that, totally fine, but then you just don’t belong very much to this very conversation.
I see your point, but this feels like a difference in workflow philosophy, especially with AI-assisted coding becoming more common.
With jj, your working copy is always a commit. This encourages a "commit often and messy, clean up later" approach. You can rapidly iterate with or without AI, letting jj automatically save every change without stopping to craft perfect atomic commits.
Later, you use a simple jj squash to combine all those small, iterative changes into logical, clean commits before you share it. The atomicity is created retroactively, not upfront. For a finely-tuned magit workflow this might feel wrong, but for rapid, exploratory and AI-driven iteration, it's a more natural fit.
With AI there’s even more reason to have ergonomic splitting if you care about quality commits, since unless you always write the perfect focused prompt, AI can over-generate for the scope of a single commit, so sooner or later you need to split that commit during the cleanup process you mentioned.
I’m using jj for almost a year now and I definitely feel much happier whenever I need to rebase a branch or do an octopus merge. It really is liberating in an incremental way that creeps on you in day to day work. Don’t expect a revolution, though.
Small commits are the same small commits in jj as in git, you just split instead of add -p.
What does the magit interface for staging look like? I only used GUIs were you select the lines with the cursor or mouse and stage that. Is it like that or more sophisticated? Does it support editing hunks better, because that's a thing I only do on the commandline, because my Git GUI doesn't support that.
In magit, the diff is splitted into sections: Untracked, Unstaged and Stage. The sublevels are files then hunks. You can stage and unstage hunks, files and whole section by pressing s and u. Pressing k discards the node (section, file, or hunk.
You can also stage or unstage lines by selecting them first and press the relevan keys.
If you press ‘return’ on a hunk, it brings you directly the the line to edit.
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.
There's more than one way to do it, but the very normal UX is that you can just scroll through the diff file-by-file and stage/stash/drop each hunk individually by placing your cursor over it and issuing the appropriate command. You can do the same with files, staging/stashing/dropping changes to a file by placing the cursor on its name and issuing a command.
And you can even edit the content you stage, so that you can stage something different, than what is in the working tree. Having different content in the index vs. working tree is the feature of the index, which I think JJ just doesn't support?
As an stgit user, this seems like a weird workflow to me. I never want to have that many uncommitted changes just floating around that will eventually belong to multiple commits. If I'm halfway through something and realise "oh, it would be good to do xyz first" I don't want to have xyz's changes and my half-way-through changes all mixed up -- I want to pop the half-way-through stuff, do the xyz stuff and commit it, then re-push the half-way-through stuff to keep working. If I'm looking at a diff and picking out parts of it then I've done something wrong -- I have a tool for doing it but I only need to use it every couple of months...
I end up with "neatly separated does-one-thing commits" but I get there by building them up as I go along, not by writing a ton of code and then trying to split it up afterwards.
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...
But there are dozens of great UXs on top of Git already, so if that's 95% of what jj is about then you seem to be making an argument for jj adding very little value. My understanding is that jj offers more than just UX enhancements.
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.
If a product is 10x better than what's currently available, it will see rapid adoption. There was obviously something about git that made it MUCH better than the precursors and that's why it obliterated everything else.
I highly doubt that new tools will be 10x better than git. Maybe 20%?
As far as I can tell, jj intends to be more like a cross-VCS frontend (with their own native backend coming at some point). If tooling supports jj, it would automatically support git, jj's native backend, Google's hybrid backend and any other backend a user could add.
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 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 think 'jjhub' is a decent immediate first approximation, and is often how I've started out talking about it with people. At the same time, we have to offer real value here, as you can already use jj with github (and I have for a long time now), so there's more to it than that. But yes :)
If you're starting over with a new backing store using jj's pluggable backends, can you give us a native lazily-materialized store for megarepos? It's a tragedy that the open-source world has no answer to piper.
- Everything locally stored in the repo: PRs, comments, issues, discussions, boards, ...
- CLI first
- Offline first (+ syncing)
- A website for hosting/presentation
Noted :) In another comment I linked to beads, which is a cool project to keep your issue tracker in your repo, but that's just a personal thing, no comment on what the company plans to do (or not) in this area.
I use command-line tooling much more than IDEs (e.g. VS Code), so the `gh` command-line tool (https://cli.github.com) for doing most of the usual hub-oriented workflow (PR authoring, viewing issues, status updates, etc) really helps a lot - I don't have to constantly <cmd>+<tab> to my browser, and point-click-point-click through web pages so much. It would be fantastic if ersc or any other jj-centered code-sharing hub had similar tooling early on.
When I tried Fossil it had things weirdly separated.
I was expecting when I make a commit, I would have the facility to specify what issues it addressed and it would close them for me automatically. It seemed there is so much opportunity there to "close the loop" when the issue tracker, etc and integrated in your VCS, but it wasn't taken.
That's my favourite thing about fossil though. History is what it is, not simplified to look "clean" (i.e. hide what actually happened and when) and you get a lot fewer footguns to ruin everything by accidentally rebasing things to the wrong place without noticing.
I personally find this to be more interesting simply because it has the social inertia of Bluesky behind it. Software has centralized on GitHub because it is discoverable there. Software on Tangled is discoverable through Bluesky, and the stacking support to make jj nice to use with it is just an added bonus.
> 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?
In fairness that's not much different from any other internal Google tool. Those don't often have a two-digit years shelf life.
I'll venture that jj is there to stay, however. If not at Google, then in general. It's just too much of a quantum leap. I think I've finally identified what about it sits so right with me: a change's identity is preserved through its revisions. In bare git, after a rebase or an amend, you get a wholly different commit that just happens to have a similar content.
Mind you, I'll also venture that jj will remain based on git as its storage backend, despite its stated goal otherwise. Git's internals are just too good at what they do to make it worthwhile to replace them.
I hope it sticks around so that I can use the same workflow at work and home. I'm really enjoying how fast all the jj operations are compared to mercurial.
The git wrapper was never fully supported and had some rough edges (I think it was only ever a 20% project, and also its, like, really old). And the customized mercurial has been around for more than 7 years, I think close to a decade (the client I'm using right now is turning 7, and it wasn't my first one).
I used git5 from when I started in 2011 to when I left in 2017.
I'm going back starting on monday, so I'm curious to try out jj.
In the past 10 years it's all been github and gitlab, and their code review tools are so painful, specifically w.r.t. tracking discussions across revisions. I never felt excited to try out jj because I was afraid it would that situation even worse.
I started using git as my daily driver at Google in 2018. I was forcibly kicked off it for mercurial in 2020. The deprecation plan for mercurial is 2026 IIUC. Maybe if you adopted mercurial early it's different.
Why did Google decide to choose Mercurial? Based on what I read the main reason was that the mercurial dev team was willing to prioritize features needed for Google to add custom extensions to support its monorepo, and the git dev team wasn't going to reprioritize just for the sake of Google.
Yes, that's correct. Another reason was that Mercurial is easier to customize because it's written in Python so we could sometimes just replace whatever we needed without needing much changes from Mercurial itself.
Yet another reason is that the .git directory is considered a documented API and several other tools and libraries depend on it (e.g. JGit and libgit2). So any new features for Google would need to be made to those tools too if we wanted things built on them to work.
I can second that the aforementioned reasons are true. The funny difference is that Google employs the primary git maintainer. Git has a lot of customers though so it rightfully is very conservative with development.
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.
> do I get any benefit from the change id if I push to GitHub for PR review?
As of right now? Not really. The details are more complicated, but basically, if your project doesn't like the behavior of github when it comes to comments + editing commits, and wants you to tack on new commits instead, we can't change that behavior. However, https://github.com/LucioFranco/jj-spr can, in some situations, give you some of this experience. If your project is okay with editing commits, then it can help you locally, sure.
However. In an interesting turn of developments, GitHub's new SVP just tweeted that he's likes jj and is interested in adding stacked diffs to github. I don't know how this squares with their "no new features for 18 months" thing, but we'll see!
> But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in.
It's not code review, it's issue tracking, but I've been using https://github.com/steveyegge/beads this week, and I think it might be the first "put your issues in your repo" system I actually enjoy. It says it's built for AI stuff, but like, you don't have to use AI with it.
One thing to note is that the actual commit objects you make through jj do include a `change-id` header which means that even though Github is unaware of jj, peers using jj will still be able to keep track of the rebases.
Demo: run `git cat-file -p HEAD` in any jj repository that you've made a change to.
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 am the last person to ever promote perforce, but as of last yearish it has the option for binary delta transfer using fastCDC.
Even without that, it is a just straight up a lot faster than git lfs. I know this because I benchmark it against git pretty frequently as I am creating my own large file capable VCS.
What do you mean by this? It's hardly equivalent to LFS. The binary files aren't replaced with a text pointer with actual content stored on a server elsewhere. Binary files are stored in the same place as text files.
From the user's perspective, when setup correctly Git LFS is transparent and they don't see the text pointers - the binary files are replaced on push and pull to the server.
It's the same user experience as Perforce?
Yes, Git is more low-level and it's possible to see those text pointers if you want to.
This is what you want to believe but its not true.
I’m really sorry, git lfs is an ugly hack, and its always painful when you discover that some gamedev team has been forced into it by “better knowing” software developers.
It reminds me a lot of “features” of software that is clearly a box ticking exercise, like technically MS Teams has a whiteboard feature. Yet it lacks any depth: its not persistent so its gone after the call, and it’s clunky to use and to save.
… but technically the feature exists, so it’s harder to argue for better software thats fit for purpose, like miro or mural.
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.
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)
That line wasn’t even in the original post. It is not nearly the only technical advantage. The point of the post is just not about that topic, so that content is not in the post.
This is very funny. People just love jj! There are no conflicts of interest, at least not until now that there is a company built around jj. But they also started it because they love 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.
That's called a merge commit. You can even group them further by creating merges of merge commit. It requires you to merge in the right direction though.
This is an interesting idea... jj has a templating language, but it's not stateful, so you couldn't like, hide some commits based on other commits, for example. But I'll file this away...
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.
stupid question: can someone with a deeper understand kindly explain, why are talks lurking around the corner about hopping version control systems, whats wrong with git that jj solves?
There's a variety of things that all add up to a very pleasant experience.
For starters, git has a poorly-designed UI, whereas jj borrows from Mercurial, which was widely-considered to be better designed from a DX perspective. I can usually guess what commands and flags to use on jj without reading the manual; not so for git. E.g., `jj undo` undoes anything you might have done; For anything esoteric in git, I consult ohshitgit.com because there's half a dozen different commands to know to undo everything.
Another is a simplified model whose pieces compose better with each other. There's no need for staging or stashes in jj. You essentially work in a HEAD commit all the time, and when it's ready, you commit what you want, make a new child commit and keep going. A stash is just some random commit. Anything you've learned about manipulating commits now applies to "stashes" with no extra effort.
No need for branch names. If you come from git, learning that "stashes" are just random little HEAD commits may make you groan and think you have to give each of those branches a name. jj doesn't care about that. I still give major branches a name, but since I don't have to name them in general, it's easier to create lots of little branch "experiments". Branch names were never really a substitute for commit messages, anyway.
More rebase-friendly IDs. Git penalizes the use of SHAs when rebasing, whereas in jj, change IDs are stable after rebasing, making them actually usable. This makes rebasing easier and safer.
First-class conflicts. Git forces you to stop the world and deal with conflicts immediately, or back out entirely. This isn't really required, and jj has no opinion. It marks conflicted changes, and waits for you to get around to fixing them. This is great when your boss interrupts you for something high-priority. It also automatically rebases all downstream changes after you've fixed it, which usually clears their conflicts too.
Megamerge workflow. This is possibly doable in git, but I don't know how easy the workflow is. But in jj, creating a work commit that has multiple branches as parents is trivial, as is pushing work down into individual parent branches. This makes integration easier, as you can easily see how your upcoming changes interact with your colleagues' upcoming changes.
Jujutsu's not a revolutionary VCS change (like Pijul's theories of commutative patches), but it's generally way more pleasant to use, with better DX, than git. I gave up git forever after two weeks of jj.
What the JJ developer seam to misunderstand is, that the index and stashes are a feature to improve the users workflow. You can bypass the index with commit -a, giving you JJ behaviour and you can commit just fine instead of using the stash. The stash is like some backlog of temporary commits and also supports saving the index separately. When you don't care about this, you don't need to use it, these features are purely additive.
I would love the git index to not be a thing you had to care about unless you deliberately wanted to use that feature, but in my experience this is not the case...it feels to me like an implementation detail that surfaces into the UI more than it ought to.
thank you for the detailed explanation. let us say you want to edit the contents of a commit on git 10 commits ago and this was not pushed to remote. you would do a rebase which basically discards and underneath basically creates a new track to follow. How does jj rebase work? I heard you can actually edit something 10 commits ago in jj and it treats it natively as an edit
I'm not sure what you mean by "natively as an edit", but jj really doesn't care if you alter some commit 10 back from the branch tip. Everything is automatically rebased as needed, and unless you introduce conflicts, it's seamless.
The typical workflow would be:
1. `jj log ...`
Locate the change ID of whatever change needs altering.
2. `jj new $SOME_CHANGE_ID`
This creates a new, empty change whose parent is the change you want to edit
3. Make your changes, pass the tests, etc.
4. `jj squash`
All your changes get squashed into $SOME_CHANGE_ID
5. jj then automatically rebases everything downstream of $SOME_CHANGE_ID for you.
All jj change IDs remain the same (though the underlying git commit SHAs are now different.)
If there are any new conflicts introduced in the downstream changes, they'll get flagged. You'd then typically run `jj new $FIRST_CONFLICT_ID`, and repeat the whole process.
---
It's also possible to run `jj edit $SOME_CHANGE_ID`, to work directly on that change, but because of the automatic rebasing, it's preferable to work on a child commit and only squash when ready. (In case you need to do other things with downstream changes before you've finished making your updates.)
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.
That's exciting! Have you guys looked into sappling from Meta as well? It looked really cool the last time I looked into it but never tried to use it much.
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 ask gpt-5 about doing something in jj the other day, it didn't even recognize it at first.
Using VC commands an LLM generates for you sounds like a pretty terrible idea anyway. What if they delete your data? Why not spend 5 minutes searching for information written by a human?
I'm not running them blindly and I do always ask the llm to explain the command since the end goal is not to have the llm do the work but rather for me to learn jj.
+ any good tool will not let you run destructive commands without confirmation unless it's with some force flag and I have enough computer knowledge to not use force flags blindly.
+ "information written by a human" can be unreliable too.
I do think that GUI stuff is important, there's a lot of folks who have said "not interested unless there's a magit equivalent" which I totally understand. I'm not a big GUI person for VCS myself, so I don't feel the same pain.
For LLMs, yeah this is hard for any new project. I use Claude Code, and it does a decent job with jj, it only tries to do git stuff sometimes. I haven't asked ChatGPT about it though, I'll have to experiment with it myself.
What a terrible world we're barrelling towards when "LLMs don't know about it" is considered a blocker towards something taking off. Read a blog post, read a man page (which GP says was indeed their solution), or just play with the dang tool, I assure you these things are still possible without the assistance of a predictive text engine helping you!
One problem is that Stack Overflow isn’t being updated with questions about new tools because it’s been crowded out by LLMs, so the LLMs can’t train on these nonexistent new questions/answers.
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.
As long as some repository state in either system can map onto a checkout in the other system it should be possible at least in some capacity. I’d like to try out pijul at work, but I’d need an analog of jj git fetch and jj git push. Whatever happens in between doesn’t really matter too much unless it’s tedious manual bookkeeping to maintain history mapping.
At the risk of being unreasonably negative, stuff like this just makes me feel... tired. Git is... fine. I'm sure it doesn't solve every problem for everyone, and oh boy does it still have many rough edges, but it works and (as the article points out), git has won and is widely adopted.
I've extensively used CVS and Subversion in the past. I touched Mercurial and Bazaar when I ran into a project that used it. I remember in the CVS days, SVN was exciting to me, because CVS was such a pain to use, in almost every way. In the SVN days, git was exciting to me, because SVN still had quite a few pain points that poked me during daily use. Again, yes, git had and has rough edges, but nothing that would make me excited about a new VCS, I don't think.
Maybe I'm just getting old, and new tools don't excite me as much anymore. Learning a new tool means spending time doing something that isn't actually building, so my eventual use of the new tool needs to save me enough time (or at least frustration, messily converted into time units) to balance that out. And I need to factor in the risk that the new tool won't actually work out for me, or that it won't end up being adopted enough to matter. So I think I'll wait on jj, and see what happens. If it ends up becoming a Big Deal, I'll learn it.
I think being conservative about tool use is totally fine! I'm actually pretty conservative about most of the tools that I use.
The goal of this post wasn't really to convince anyone on why they may want to give jj a shot, more of just a post about how I think about technologies I may want to spend my limited time on this planet working on, and announce that I'm making a move.
I don't think that you're being unreasonably negative. I think it's crucial for technologies to understand that your position is basically the default one, and that you need to offer a real compelling reason to choose a new tool. For some people, jj has enough of that already to bother with choosing, but I think the real power is in things that aren't widely available yet. Hence the need to go build some stuff. It's early days! Not even 1.0 yet. It's very natural that most people do not care at this stage.
Sure, definitely, sorry for being a bit off-topic, clearly this was about you and your plans and not intended to be about jj itself.
Having said what I said, I do find new tools to be interesting, and I do hope jj ends up being successful. I'm always happy to be surprised by something that fixes problems that I didn't consciously know I had, or that adds new features or work modes that make my life easier in ways that never would have occurred to me in the first place. I was a pretty early git adopter, and it works great for me, but I'm sure a decent chunk of that is because I understand how it works under the hood, even if it often doesn't present a great UX.
And even if jj doesn't eventually surpass git's popularity, it's great to have other options, and avoid monocultures.
So for me, the most compelling thing about jj is that it is somehow simpler than git, while also being more powerful than git.
What I mean by simpler is, there's fewer features, which makes things easier to pick up, because these features fit together in a way that's more coherent than git's. By more powerful, I mean jj lets me regularly do things that are possible, but annoying and/or difficult in git.
I loved git. I was never the kind of person who thought its CLI was bad. But then, when I found jj, I realized why people thought that.
As someone who loves git, has always thought the criticisms about its interface were overstated... but also feels like it maybe has too many incoherent ways of doing things, this is the best sales pitch I could've asked for (and I came to the comments to ask for a sales pitch). Thanks - I'll try jj out the next time I start a hobby project.
Another good sales pitch is `jj undo`[0]. It puts the repo back to previous state, regardless of what the mutative operation was. It's a powerful and simple safety net that unlocks experimentation.
It does this by adding an new operation on top of the operation log[1], so you don't lose repository states by moving up + down the op log. There's a corresponding `jj redo` as well.
jj undo is great but it's a one time thing. You can't do jj this, jj that, jj other, jj undo, jj undo, jj undo AFIACT. You have to look into the op log and jj op restore for that. It's nice you can get back to where you were though.
The biggest issue for me is it requires active change management (or feels like it). In git I do `git checkout foo` then I start editing. If I want to see what may changes are since foo then `git diff` tells me. With jj though, `jj edit foo` is the to git, state of the repo ALL changes to foo. So any new edits are invisible. So, instead of `jj edit` I have to do `jj edit` `jj new`, then later squash those into foo
I know there are similar cases in git but I guess I'm just used to git so I wasn't using those cases.
that said, I'm mostly enjoying jj. Though quite often i get a conflict I don't understand. Today I got 2 and it told me choose A or B. I did `jj diff -r A -r B` and it said no diffs. If no diffs aren't there no conflicts? I'm sure someone gets it but it was annoying to just have to pick one to abandon
> You can't do jj this, jj that, jj other, jj undo, jj undo, jj undo AFIACT
You can as of v0.33.0[0]. Previous behaviour was that `jj undo; jj undo` would leave you where you started (it undid the undo).
> The biggest issue for me is it requires active change management (or feels like it). In git I do `git checkout foo` then I start editing. If I want to see what may changes are since foo then `git diff` tells me. With jj though, `jj edit foo` is the to git, state of the repo ALL changes to foo. So any new edits are invisible. So, instead of `jj edit` I have to do `jj edit` `jj new`, then later squash those into foo
I'm not 100% clear on what you mean here, but a few things that might help:
1. In jj you don't "checkout" a branch, you edit a specific commit. That commit might be pointed to by a bookmark but it doesn't have to be. A jj bookmark is roughly equivalent to what git calls a branch. Note that a git branch, and a jj bookmark are just pointers to a commit, as illustrated here[1]).
2. If you want to resume work on a branch/bookmark instead of `git checkout BRANCHNAME` you'd do `jj new BRANCHNAME` which puts a new commit on top of the commit and sets it as a working copy.
3. Bookmarks don't auto advance like they do in git. So adding new commits on top of a "branch" will leave the bookmark where it is until you `jj bookmark set/move` it. So you could squash commits down into the "foo" bookmark, but you could also move "foo" to point to subsequent commits.
4. Not sure what you mean by edits being invisible, but if it's seeing a diff from main to the tip of your branch (with a change id of ex. XYZ) it would be `jj diff -f main -t XYZ`.
I’m not sure if it’s a typo, but you don’t need to edit and then new, you can just new. It’s a good habit to get into as a replacement for checking something out.
I’m not sure what happened in your conflict situation either, that does sound frustrating. EDIT: Oh, I wonder if it was this: https://jj-vcs.github.io/jj/latest/technical/concurrency/ specifically, that I bet the repo was being modified concurrently, and so you ended up with a divergent change.
You're welcome, and feel free to let me know how it goes. There is an adjustment period, for sure, and (in another eerie parallel to Rust) some folks try it, bounce off, and try again later, and it sticks then.
The auto-commit behavior was one of my biggest concerns when starting, but it turns out that when combined with other things, I'm a huge fan now, for example.
Just my feedback - I've personally found jj more complex for simple projects. Like if you have a non-collaborative repo where you push to main most of the time after making a series of commits, in jj you have to keep updating a bookmark before pushing it and there's no one command to do both.
If you have another machine on main without any outstanding changes and you want to pull the latest changes that is probably also two steps (git fetch + new?)
That said, I've been liking jj quite a bit for more mature / collaborative projects. It has been a learning experience. (don't enjoy updating bookmarks for PR branches though; jj encourages rewriting history which is not my favorite choice for code review branches; I often work in repos that squash-on-merge).
For updating bookmarks I've found like half a dozen variants of `tug` alias the community has come to using which is just a slight improvement (bit daunting to newcomer to pick 'best' one and not fan setting up aliases on all my working devices).
It would be nice if jj was better than git for the fundamental workflows like this out of the box overall.
Right, “parent branch” implies a tree structure, but git is a DAG.
You might have a specific workflow such that you can actually answer your question, but it won’t generally apply to all repos.
Since a branch is really just a label for a specific commit, which may be at the end of a chain of successive parent commits, a branch isn’t really a first class structure, but a derived one.
You can get the fork point of a branch, which is a common ancestor commit shared by another branch, but that fork point is a commit and may not have a branch label. That commit can have any number of other branches going off of it: how would you decide which one is the parent vs just another sibling?
My assumption after looking at jj is that it is not as complicated as git yet. Give it time. It’s also not even as simple as git for many tasks, based on their own docs: https://jj-vcs.github.io/jj/latest/git-command-table/
I don’t think you ever need to do this, jj tracks changes much better than git, assuming I understand your question. E.g. you can rebase a whole local change dag based on a commit from origin with a single jj rebase -b and it’ll move bookmarks (git branches) correctly.
That's even less how jj works, unfortunately for this use case, because jj doesn't require branches to be named.
You could probably attach metadata to commits indicating the branch name at time of creation, but there's probably a lot of weird edge cases to handle.
It's technically a bit more than that. JJ is its own VCS, with pluggable backends. Google has a closed-source Piper backend, the git backend is the only real open source backend. But at high level, it's fine to think about it in that way, yeah. I tend to think about it as being more "able to work on git repos" than as a UI.
Git's CLI is awful compared to fossil or even mercurial. Jj seems like an improvement over git, but it lacks a web UI like fossil has. It's very useful. Basically like a self contained github lite, only without the needless complexity, the enterprise bs, the annoying login process, tokens, passkeys, brain damaged permissions system etc.
I used to think the same way about jj not too long ago. I even wrote a few comments here similar to yours, but since then I’ve changed my mind.
For me, the turning point was realizing that jj actually eased some of the frustrations I had with our rebase workflow at work. It took a while for it to click, but now I wouldn’t want to go back
In my day to day, its basically "git pull --rebase repo branch", plus some interactive rebate to squash commits, and it's not particularly frustrating, so I'm curious what you're doing that we're not.
Basically the same except in some projects we are not supposed to squash. So, sometimes we end up with long long histories to be rebased onto other long histories.
rerere only helps so much with conflict resolution but with jj I think it is as painless as it could be.
I think yours a perfectly reasonable stance, and I often feel the same way. And all this complaining about git is getting tiresome, especially if you had to deal with its predecessors.
FWIW, I still tried out jj and found it a joy to use. I use it all the time now. Most of the time, it not only gets out of your way, but rolls out the red carpet. I'm saying that as someone who knows their way around the git command line. t's like replacing your trusty old remote control with a new one where the buttons are well labeled, ergonomically placed, that lets you do entirely new useful things, and it has a universal back button that just works.
Maybe jj is an especially good fit for my way of working, but I do think that it is a real, actual improvement for everyone.
And it's super easy to pick up anytime. So yeah, I think you're doing it right! Sit back and let it come your way. From what I can see, there's a pretty good chance that it will.
jj is actually so good though. People don't need to know you're using it, which is why it's nice.
A problem I run into when working with other people is that code reviews take forever and I need to build on top of them. Code gets merged while it's being reviewed, and it becomes a burden to keep rebasing your stack of PRs. It's also difficult to do things like designing each PR against the main branch, but testing all 3 of them together. (Sometimes you want to write the docs / take screenshots as though all your features are merged as-is.) jj makes all this trivial. You tell it what you want and it does it without involving an index or working copy or interrupting you to resolve conflicts.
I've found that it really makes me less annoyed when working with other people. I don't know why it takes people longer to review code (or to even open the review request) than it takes me to write things. But it does, and jj is what keeps me sane.
To be fair, I also use it on personal projects because sometimes you have 3 things you want to try at once and they're not related to each other. Upstream isn't going to change without your understanding, but it's still mechanically something to maintain the rebases on those 3 branches. jj just makes this burden go away.
Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git.
> Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git.
When you make a change to a pr in response to review feedback, do you just jj edit it in, and end up with a force push on GitHub? After which the review comment might get detached from the code or even hidden.
That's definitely something that could be better for me. (That said, there are other projects making it better too.)
Without knowing much about jj, isn't this more of a problem in how the GitHub/GitLab/Forgejo Pull Request system works rather than a jj problem?
Patch-based workflows in general (where you heavily use git rebase -i to curate a smaller set of "perfect" commits for anything you'd PR, rather than just piling new commits onto every PR) don't work well with the GitHub approach, which heavily favors merging stuff through the web interface (making merge or squash commits along the way).
You can make it work of course, but GitHub tends to behave in weird ways when it comes to how it's interface works with patch-based workflows. Perhaps a better estimate would be to see how it compares to a forge like Phorge or Sourcehut.
Yes, that's why I asked it as a response to them saying GitHub was just fine :) With Git, I work around it by adding `--fixup` commits and then doing a final `git rebase --autosquash` just before landing it, but it would be nice to have a better workflow.
(The mention of the GitHub SVP being interested in stacked diffs sounds good in that regard. I'm also keeping an eye on Tangled and, now, on ERSC.)
Yeah, I always force push. I always treat PRs as one atomic unit ("squash and merge") and the history that goes into the PR isn't relevant to me after it's merged. Maybe once or twice I've regretted this (maybe you want to backport one part of this PR to the release branch, and now you have to manually create that) but in general, how something is made can be ugly and it feels good to me to erase it when something is ready to be merged.
I guess in terms of clean workflow, I could get into that more using jj (i.e. create a PR for every bit that I want to have in the history later), but as a reviewer, I always get annoyed when I have to do a re-review of something that was force-pushed, and I'd like to avoid doing that to others. So I was kind-of hoping you had found some magical silver bullet there, haha.
I use git but I instead just keep all PRs stacked on top of each other and rebase when one is merged. If something is easy to review I push it down the stack. If something is harder to review I keep it at the top of the stack.
I don't open a PR for each commit, and we use squash commits at work which makes it harder to have this workflow but it still works fine for me.
I rebase only the leaf PR, and I have update-ref enabled to update the branch refs of all other branches in the stack. It works well. The only manual process is that I have to manually force push each branch afterwards.
Lastly, I use the `-x "cargo fmt" -x "cargo clippy"` feature when rebasing (which is missing in jj) to make sure the stack stays in a good state
It is not even close to sufficient. jj fix only executes the command on one file at a time (only the changed files) so it can't work on anything that has linter semantics.
jj does this for performance reasons. They don't want to perform a full checkout for every rebase action. This is simply something I disagree with
> jj does this for performance reasons. They don't want to perform a full checkout for every rebase action.
It's true that `jj fix` can be faster by not touching the working copy, but we also want a `jj run` command for the linter feature (https://github.com/jj-vcs/jj/issues/1869). It's just not done yet.
I have a question and you might have an idea about this:
I have a workflow where I have my main and a bunch of branches that are children of other branches. So: main, branch_a, branch_a_1, branch_a_2, branch_a_1_x, etc. Probably not a good workflow, but that's what I do.
I keep editing old commits in my branches to have clean, atomic commits, which fucks up my branch structure and I need to cascade-rebase everything manually.
Do I understand correctly that jj does it automatically?
The good thing is that a new player entering the arena allows a fresh look at certain problems, and some solutions then get backported to the OG project. I've read it already happened that jj inspired some changes in git.
Same happened e.g. with nodejs getting deno and bun around, which allowed to break nodejs' inertia on many problems that the others have solved.
I've also worked with CSV (barely) and SVN (more extensively) and I was blown away by Git.
You can have real branches! Many of them! You don't have to manually merge them! It's decentralized, you can have multiple origins, it lets you work offline! The list goes on and on.
There were many compelling reasons to switch to Git. But for all the articles about jj out there, I've never read any compelling reason to switch to jj. "It easier", "the commands are somewhat more ergonomic"... that's all?
You don't need to switch from git to jj. You just try out jj on your git project and see if it clicks. If you don't like it, you just don't continue using it.
One thing JJ has that git doesn't is the concept of first class conflicts. In JJ, rebasing or merging never fails, but it might record a conflict to resolve later. Git, on the otherhand, forces you to drop we everything to resolve conflicts immediately. It sounds like a small thing - but in my experience, being able to resolve conflicts later when I feel like it is absolutely amazing and really helps reduce context switching.
I learned all of cvs, svn and then later git when getting into Linux and Open Source. Based on my early experience of multiple systems, I'm very surprised that git has dominated and lasted this long already!
I used to think this, too. Tried jj a few times before it clicked.
It’s very liberating in some ways, in others it’s simply no worse than git. You can do everything you can do with git, but some of those things don’t require multiple steps or n repeats of the same action. jj rebase + commitable conflicts + jj undo = freedom and peace of mind.
Fair points. I'm also generally happy with Git myself.
I've been exploring JJ mainly for its slightly different approach to change tracking (~every change gets tracked, at least initially, rather than just commits).
Stacked PRs also look interesting but I haven't had an occasion to try them out yet.
I personally feel quite capable at git and am not looking for another flow or tool.
But. I think it's incredibly useful for organizations to have patterns for how they use git. There can be huge variance! And there's so many people who don't feel comfortable doing interactive rebases (of their feature branches), or other serious monkeying with history.
(I also think jj's flows are incredibly good about avoiding accidental loss of work in a way that git can be extremely dangerous at.)
I think there's a ton of value to having more of a pattern than the free-form jamming that git gives us. The real value I see in jj is that it's more than the toolbox of things git gives one: it's something more learnable, teachable, and directed than git. And it seems to do it pretty well, with style, and less monkey business. I'm still super greenhorn at jj, and honestly lacking the need for it, but I'm excited to see it come along. Especially since it is compatible with so many other VCS.
I'll be honest, I did too. No https cert makes it give a warning in Chrome, which I had expected to just be a 404, and was surprised when it actually worked!
Does JJ have equivalet functionality to git's format-patch and am? Because I, for one, am rather fond of the e-mail based workflow and not having that would make JJ a no-go for me.
There hasn’t been a ton of desire for it because it’s easy to just run git format-patch. Jj’s workflows feel closer to the email workflow than not, but prioritization in a young project is tough.
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.
This is one person's career move that is defended by the idea that they somehow always make good bets. This is more than a bit arrogant. Past performance is no guarantee of future results.
I don't see a future for this. I see a series of blog posts that culminate in a tone deaf "What went wrong" finale.
> There are no substantial technical or usability reasons to switch to JJ from Git [...]. This is a neutral impersonal opinion that is virtually a fact.
> it's impractical for most working programmers to switch
I don't know what you mean here. I think it's quite practical to switch to jj, and people switch over all the time. Some people are going to be earlier adopters than others, but the early adopters can bring others along (as I've been lucky to do at Oxide).
> focus on something whose main appeal is more than social
Steve and I both think that Jujutsu's appeal is far more than merely some bandwagon effect. I do think that social appeal is an important part of making a project succeed, and that projects without substantial technical merit win due to social appeal all the time, but Jujutsu has both! It's amazing!
Perhaps take a look at jj and give it a go. Maybe you’ll like it.
I know I did. The fact I can use it with git and it doesn’t interfere with any GitHub PR workflows means no-one needs to know I use it. I enjoy the jj model. Maybe you could too, and it’s not a crazy investment of time and energy. It’s an evening playing around with a code kata or something.
Then working with vcs becomes that little bit more enjoyable.
> There are no substantial technical or usability reasons to switch to JJ from Git and it's impractical for most working programmers to switch. This is a neutral impersonal opinion that is virtually a fact.
Not a thing in here is true, especially not objectively true. As neutral as you may believe yourself, it might be a good time to step back and reexamine your priors that led you to state so confidently that there’s no usability reason to switch in particular.
> it might be a good time to step back and reexamine your priors that led you to state so confidently that there’s no usability reason to switch in particular.
The key word I used is "substantial." The usability improvements over Git are marginal and if they ever become non-marginal, they can relatively easily be added to git. This is what my comment is getting at. The only essential difference between Git and JJ is that they are different fiefdoms. There is no substantial technological difference. It's just two different social factions with marginally different opinions about how to type CLI commands.
Changesets, the op log, first class conflicts, no staging area.
JJ might produce commits that can be stored in Git, but the affordances are different. If Git wants to adopt them, it becomes no longer Git.
On the other hand, I'm happily using JJ while everyone I collaborate with is using Git. JJ doesn't need to "win" to be useful, it just needs to be useful enough that the people who maintain it continue to maintain it.
> There are no substantial technical or usability reasons to switch to JJ from Git and it's impractical for most working programmers to switch.
Not in my experience. jj is easy to pick up and a joy to use. I like git. I deeply appreciate git. But git can feel like snow shoveling sometimes, while in jj things just click into place.
jj is freeing, because things that were a hassle before are now easy, and other things that were impossible are also easy.
I know there's a lot of hype around for a lot of things, and I get grumpy from all of it. Jujutsu is one of the few things that actually deserve the praise being heaped on them.
You may disagree, of course. But I hope that some day, you'll have reason to be happy about this tool, instead of feeling... whatever touched you off like this.
This comment could have been written when people were pushing to SVN repos on SourceForge when Git was becoming the next big thing, enough for a competitor to founded.
Yet still, the status quo is not Subversion and SourceForge, both of which have been relegated to antiquity, but git and GitHub.
Will something else unseat git and GitHub in the coming years? And will it be Jujutsu or some other innovation on version control?
Who knows, but I see no need to be so dismissive of somebody’s passion in such an arrogant way.
These are my thoughts exactly. Focus on building the best thing instead of telling everyone about the dreams you want to reach. Speak softly and carry a big stick as it were.
> There are no substantial technical or usability reasons to switch to JJ from Git
Every magit user disagrees with you.
> and it's impractical for most working programmers to switch
This very much sounds like someone who has never even tried jj. Tell us: What makes switching impractical?
> My well-intentioned recommendation to Steve, because I've been there, is: If you want to avoid feeling like you've wasted your life in a few years on code that doesn't live up to its promise and is essentially no different than the code that already exists in Git (and Hg, Pijul, Fossil, etc.),
I was thinking, it'll probably catch on like Omarchy did, except it's written in Rust, so... little chance of it being milkshake-ducked.
But as we say on Hackernews, there are two kinds of people with respect to jj: those who love it, and those who haven't tried it.
Doing the same thing, but with better usability, is immensely valuable. Remember, Hackernews thought Dropbox was "just" ssh+rsync, but they made a billion dollars making that easy.
I’ve tried it. I don’t love it or hate it. It’s more of a “meh”. I can see how it’d be nice if I was disciplined about my commit history, but I tend to be fine with chunky, clunky git. I don’t spend as much time curating perfect commit history as jj fans seem to.
Does not sound any easier or more intuitive than git.
Focus on judiciously: mostly (functionally) atomic commits that are not every tiny change, not largely meaningless time-based snapshots, not Gerrit-style single commits for entire features, etc. I’m well aware of the mental leap you’re talking about, it’s neither hard to understand nor the liberation you might think it is. To achieve what we want to achieve we either need to be able to split, or “commit” with such atomicity that more time is wasted come squash time.* If you don’t get that, totally fine, but then you just don’t belong very much to this very conversation.
* Or we can completely change how we write code…
With jj, your working copy is always a commit. This encourages a "commit often and messy, clean up later" approach. You can rapidly iterate with or without AI, letting jj automatically save every change without stopping to craft perfect atomic commits.
Later, you use a simple jj squash to combine all those small, iterative changes into logical, clean commits before you share it. The atomicity is created retroactively, not upfront. For a finely-tuned magit workflow this might feel wrong, but for rapid, exploratory and AI-driven iteration, it's a more natural fit.
Small commits are the same small commits in jj as in git, you just split instead of add -p.
You can also stage or unstage lines by selecting them first and press the relevan keys.
If you press ‘return’ on a hunk, it brings you directly the the line to edit.
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.
I end up with "neatly separated does-one-thing commits" but I get there by building them up as I go along, not by writing a ton of code and then trying to split it up afterwards.
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.
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.
I highly doubt that new tools will be 10x better than git. Maybe 20%?
I think this is JJ's biggest advantage. Whether you use it is independent of whether anybody on your team uses it.
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).
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.
https://ersc.io/
- Everything locally stored in the repo: PRs, comments, issues, discussions, boards, ... - CLI first - Offline first (+ syncing) - A website for hosting/presentation
I was expecting when I make a commit, I would have the facility to specify what issues it addressed and it would close them for me automatically. It seemed there is so much opportunity there to "close the loop" when the issue tracker, etc and integrated in your VCS, but it wasn't taken.
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'll venture that jj is there to stay, however. If not at Google, then in general. It's just too much of a quantum leap. I think I've finally identified what about it sits so right with me: a change's identity is preserved through its revisions. In bare git, after a rebase or an amend, you get a wholly different commit that just happens to have a similar content.
Mind you, I'll also venture that jj will remain based on git as its storage backend, despite its stated goal otherwise. Git's internals are just too good at what they do to make it worthwhile to replace them.
But yeah, it's been a lot. Frankly even harder to keep track of from the outside!
The git wrapper was never fully supported and had some rough edges (I think it was only ever a 20% project, and also its, like, really old). And the customized mercurial has been around for more than 7 years, I think close to a decade (the client I'm using right now is turning 7, and it wasn't my first one).
I'm going back starting on monday, so I'm curious to try out jj.
In the past 10 years it's all been github and gitlab, and their code review tools are so painful, specifically w.r.t. tracking discussions across revisions. I never felt excited to try out jj because I was afraid it would that situation even worse.
Yet another reason is that the .git directory is considered a documented API and several other tools and libraries depend on it (e.g. JGit and libgit2). So any new features for Google would need to be made to those tools too if we wanted things built on them to work.
We also consider Mercurial to have better UX.
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.
> do I get any benefit from the change id if I push to GitHub for PR review?
As of right now? Not really. The details are more complicated, but basically, if your project doesn't like the behavior of github when it comes to comments + editing commits, and wants you to tack on new commits instead, we can't change that behavior. However, https://github.com/LucioFranco/jj-spr can, in some situations, give you some of this experience. If your project is okay with editing commits, then it can help you locally, sure.
However. In an interesting turn of developments, GitHub's new SVP just tweeted that he's likes jj and is interested in adding stacked diffs to github. I don't know how this squares with their "no new features for 18 months" thing, but we'll see!
> But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in.
It's not code review, it's issue tracking, but I've been using https://github.com/steveyegge/beads this week, and I think it might be the first "put your issues in your repo" system I actually enjoy. It says it's built for AI stuff, but like, you don't have to use AI with it.
Demo: run `git cat-file -p HEAD` in any jj repository that you've made a change to.
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.
Even without that, it is a just straight up a lot faster than git lfs. I know this because I benchmark it against git pretty frequently as I am creating my own large file capable VCS.
It's the same user experience as Perforce?
Yes, Git is more low-level and it's possible to see those text pointers if you want to.
I’m really sorry, git lfs is an ugly hack, and its always painful when you discover that some gamedev team has been forced into it by “better knowing” software developers.
It reminds me a lot of “features” of software that is clearly a box ticking exercise, like technically MS Teams has a whiteboard feature. Yet it lacks any depth: its not persistent so its gone after the call, and it’s clunky to use and to save.
… but technically the feature exists, so it’s harder to argue for better software thats fit for purpose, like miro or mural.
2. Artists can actually understand Perforce.
It has always annoyed me that there's not any clever way to handle binary changes with version control.
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.
Who upvotes this?
And there's still no disclaimer so your point is moot.
Edit: Ah in fact, just like your personal account already is, so you know how straightforward it is :)
Steve, if you come to NYC hit me up!
For starters, git has a poorly-designed UI, whereas jj borrows from Mercurial, which was widely-considered to be better designed from a DX perspective. I can usually guess what commands and flags to use on jj without reading the manual; not so for git. E.g., `jj undo` undoes anything you might have done; For anything esoteric in git, I consult ohshitgit.com because there's half a dozen different commands to know to undo everything.
Another is a simplified model whose pieces compose better with each other. There's no need for staging or stashes in jj. You essentially work in a HEAD commit all the time, and when it's ready, you commit what you want, make a new child commit and keep going. A stash is just some random commit. Anything you've learned about manipulating commits now applies to "stashes" with no extra effort.
No need for branch names. If you come from git, learning that "stashes" are just random little HEAD commits may make you groan and think you have to give each of those branches a name. jj doesn't care about that. I still give major branches a name, but since I don't have to name them in general, it's easier to create lots of little branch "experiments". Branch names were never really a substitute for commit messages, anyway.
More rebase-friendly IDs. Git penalizes the use of SHAs when rebasing, whereas in jj, change IDs are stable after rebasing, making them actually usable. This makes rebasing easier and safer.
First-class conflicts. Git forces you to stop the world and deal with conflicts immediately, or back out entirely. This isn't really required, and jj has no opinion. It marks conflicted changes, and waits for you to get around to fixing them. This is great when your boss interrupts you for something high-priority. It also automatically rebases all downstream changes after you've fixed it, which usually clears their conflicts too.
Megamerge workflow. This is possibly doable in git, but I don't know how easy the workflow is. But in jj, creating a work commit that has multiple branches as parents is trivial, as is pushing work down into individual parent branches. This makes integration easier, as you can easily see how your upcoming changes interact with your colleagues' upcoming changes.
Jujutsu's not a revolutionary VCS change (like Pijul's theories of commutative patches), but it's generally way more pleasant to use, with better DX, than git. I gave up git forever after two weeks of jj.
What the JJ developer seam to misunderstand is, that the index and stashes are a feature to improve the users workflow. You can bypass the index with commit -a, giving you JJ behaviour and you can commit just fine instead of using the stash. The stash is like some backlog of temporary commits and also supports saving the index separately. When you don't care about this, you don't need to use it, these features are purely additive.
The typical workflow would be:
1. `jj log ...`
Locate the change ID of whatever change needs altering.
2. `jj new $SOME_CHANGE_ID`
This creates a new, empty change whose parent is the change you want to edit
3. Make your changes, pass the tests, etc.
4. `jj squash`
All your changes get squashed into $SOME_CHANGE_ID
5. jj then automatically rebases everything downstream of $SOME_CHANGE_ID for you.
All jj change IDs remain the same (though the underlying git commit SHAs are now different.)
If there are any new conflicts introduced in the downstream changes, they'll get flagged. You'd then typically run `jj new $FIRST_CONFLICT_ID`, and repeat the whole process.
---
It's also possible to run `jj edit $SOME_CHANGE_ID`, to work directly on that change, but because of the automatic rebasing, it's preferable to work on a child commit and only squash when ready. (In case you need to do other things with downstream changes before you've finished making your updates.)
---
Does that answer your question?
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.
I tried to help fix this in https://github.com/steveklabnik/steveklabnik.com/pull/125/fi..., thanks again!
Discussion: https://news.ycombinator.com/item?id=45083952
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
Using VC commands an LLM generates for you sounds like a pretty terrible idea anyway. What if they delete your data? Why not spend 5 minutes searching for information written by a human?
+ any good tool will not let you run destructive commands without confirmation unless it's with some force flag and I have enough computer knowledge to not use force flags blindly.
+ "information written by a human" can be unreliable too.
For LLMs, yeah this is hard for any new project. I use Claude Code, and it does a decent job with jj, it only tries to do git stuff sometimes. I haven't asked ChatGPT about it though, I'll have to experiment with it myself.
Give it time. Once JJ resources enter the dragnet of future model datasets, LLMs will get better at regurgitating it.
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've extensively used CVS and Subversion in the past. I touched Mercurial and Bazaar when I ran into a project that used it. I remember in the CVS days, SVN was exciting to me, because CVS was such a pain to use, in almost every way. In the SVN days, git was exciting to me, because SVN still had quite a few pain points that poked me during daily use. Again, yes, git had and has rough edges, but nothing that would make me excited about a new VCS, I don't think.
Maybe I'm just getting old, and new tools don't excite me as much anymore. Learning a new tool means spending time doing something that isn't actually building, so my eventual use of the new tool needs to save me enough time (or at least frustration, messily converted into time units) to balance that out. And I need to factor in the risk that the new tool won't actually work out for me, or that it won't end up being adopted enough to matter. So I think I'll wait on jj, and see what happens. If it ends up becoming a Big Deal, I'll learn it.
The goal of this post wasn't really to convince anyone on why they may want to give jj a shot, more of just a post about how I think about technologies I may want to spend my limited time on this planet working on, and announce that I'm making a move.
I don't think that you're being unreasonably negative. I think it's crucial for technologies to understand that your position is basically the default one, and that you need to offer a real compelling reason to choose a new tool. For some people, jj has enough of that already to bother with choosing, but I think the real power is in things that aren't widely available yet. Hence the need to go build some stuff. It's early days! Not even 1.0 yet. It's very natural that most people do not care at this stage.
Having said what I said, I do find new tools to be interesting, and I do hope jj ends up being successful. I'm always happy to be surprised by something that fixes problems that I didn't consciously know I had, or that adds new features or work modes that make my life easier in ways that never would have occurred to me in the first place. I was a pretty early git adopter, and it works great for me, but I'm sure a decent chunk of that is because I understand how it works under the hood, even if it often doesn't present a great UX.
And even if jj doesn't eventually surpass git's popularity, it's great to have other options, and avoid monocultures.
What I mean by simpler is, there's fewer features, which makes things easier to pick up, because these features fit together in a way that's more coherent than git's. By more powerful, I mean jj lets me regularly do things that are possible, but annoying and/or difficult in git.
I loved git. I was never the kind of person who thought its CLI was bad. But then, when I found jj, I realized why people thought that.
It does this by adding an new operation on top of the operation log[1], so you don't lose repository states by moving up + down the op log. There's a corresponding `jj redo` as well.
0: https://jj-vcs.github.io/jj/latest/cli-reference/#jj-undo
1: https://jj-vcs.github.io/jj/latest/operation-log/
The biggest issue for me is it requires active change management (or feels like it). In git I do `git checkout foo` then I start editing. If I want to see what may changes are since foo then `git diff` tells me. With jj though, `jj edit foo` is the to git, state of the repo ALL changes to foo. So any new edits are invisible. So, instead of `jj edit` I have to do `jj edit` `jj new`, then later squash those into foo
I know there are similar cases in git but I guess I'm just used to git so I wasn't using those cases.
that said, I'm mostly enjoying jj. Though quite often i get a conflict I don't understand. Today I got 2 and it told me choose A or B. I did `jj diff -r A -r B` and it said no diffs. If no diffs aren't there no conflicts? I'm sure someone gets it but it was annoying to just have to pick one to abandon
For what it's worth, this changed in v0.33.0:
> jj undo is now sequential: invoking it multiple times in sequence repeatedly undoes actions in the operation log.
(release notes: https://github.com/jj-vcs/jj/releases/tag/v0.33.0)
You can as of v0.33.0[0]. Previous behaviour was that `jj undo; jj undo` would leave you where you started (it undid the undo).
> The biggest issue for me is it requires active change management (or feels like it). In git I do `git checkout foo` then I start editing. If I want to see what may changes are since foo then `git diff` tells me. With jj though, `jj edit foo` is the to git, state of the repo ALL changes to foo. So any new edits are invisible. So, instead of `jj edit` I have to do `jj edit` `jj new`, then later squash those into foo
I'm not 100% clear on what you mean here, but a few things that might help:
1. In jj you don't "checkout" a branch, you edit a specific commit. That commit might be pointed to by a bookmark but it doesn't have to be. A jj bookmark is roughly equivalent to what git calls a branch. Note that a git branch, and a jj bookmark are just pointers to a commit, as illustrated here[1]).
2. If you want to resume work on a branch/bookmark instead of `git checkout BRANCHNAME` you'd do `jj new BRANCHNAME` which puts a new commit on top of the commit and sets it as a working copy.
3. Bookmarks don't auto advance like they do in git. So adding new commits on top of a "branch" will leave the bookmark where it is until you `jj bookmark set/move` it. So you could squash commits down into the "foo" bookmark, but you could also move "foo" to point to subsequent commits.
4. Not sure what you mean by edits being invisible, but if it's seeing a diff from main to the tip of your branch (with a change id of ex. XYZ) it would be `jj diff -f main -t XYZ`.
0: https://github.com/jj-vcs/jj/blob/main/CHANGELOG.md#0330---2...
1: https://social.jvns.ca/@b0rk/111709462585184810
I’m not sure what happened in your conflict situation either, that does sound frustrating. EDIT: Oh, I wonder if it was this: https://jj-vcs.github.io/jj/latest/technical/concurrency/ specifically, that I bet the repo was being modified concurrently, and so you ended up with a divergent change.
The auto-commit behavior was one of my biggest concerns when starting, but it turns out that when combined with other things, I'm a huge fan now, for example.
If you have another machine on main without any outstanding changes and you want to pull the latest changes that is probably also two steps (git fetch + new?)
That said, I've been liking jj quite a bit for more mature / collaborative projects. It has been a learning experience. (don't enjoy updating bookmarks for PR branches though; jj encourages rewriting history which is not my favorite choice for code review branches; I often work in repos that squash-on-merge).
For updating bookmarks I've found like half a dozen variants of `tug` alias the community has come to using which is just a slight improvement (bit daunting to newcomer to pick 'best' one and not fan setting up aliases on all my working devices).
It would be nice if jj was better than git for the fundamental workflows like this out of the box overall.
This is one thing that I constantly find myself wishing was in git but inevitably resign myself to knowing "thats just not how git works."
You might have a specific workflow such that you can actually answer your question, but it won’t generally apply to all repos.
Since a branch is really just a label for a specific commit, which may be at the end of a chain of successive parent commits, a branch isn’t really a first class structure, but a derived one.
You can get the fork point of a branch, which is a common ancestor commit shared by another branch, but that fork point is a commit and may not have a branch label. That commit can have any number of other branches going off of it: how would you decide which one is the parent vs just another sibling?
My assumption after looking at jj is that it is not as complicated as git yet. Give it time. It’s also not even as simple as git for many tasks, based on their own docs: https://jj-vcs.github.io/jj/latest/git-command-table/
You could probably attach metadata to commits indicating the branch name at time of creation, but there's probably a lot of weird edge cases to handle.
Makes sense. Developers I know have been wanting that.
https://www.gameoftrees.org/
For me, the turning point was realizing that jj actually eased some of the frustrations I had with our rebase workflow at work. It took a while for it to click, but now I wouldn’t want to go back
In my day to day, its basically "git pull --rebase repo branch", plus some interactive rebate to squash commits, and it's not particularly frustrating, so I'm curious what you're doing that we're not.
rerere only helps so much with conflict resolution but with jj I think it is as painless as it could be.
FWIW, I still tried out jj and found it a joy to use. I use it all the time now. Most of the time, it not only gets out of your way, but rolls out the red carpet. I'm saying that as someone who knows their way around the git command line. t's like replacing your trusty old remote control with a new one where the buttons are well labeled, ergonomically placed, that lets you do entirely new useful things, and it has a universal back button that just works.
Maybe jj is an especially good fit for my way of working, but I do think that it is a real, actual improvement for everyone.
And it's super easy to pick up anytime. So yeah, I think you're doing it right! Sit back and let it come your way. From what I can see, there's a pretty good chance that it will.
A problem I run into when working with other people is that code reviews take forever and I need to build on top of them. Code gets merged while it's being reviewed, and it becomes a burden to keep rebasing your stack of PRs. It's also difficult to do things like designing each PR against the main branch, but testing all 3 of them together. (Sometimes you want to write the docs / take screenshots as though all your features are merged as-is.) jj makes all this trivial. You tell it what you want and it does it without involving an index or working copy or interrupting you to resolve conflicts.
I've found that it really makes me less annoyed when working with other people. I don't know why it takes people longer to review code (or to even open the review request) than it takes me to write things. But it does, and jj is what keeps me sane.
To be fair, I also use it on personal projects because sometimes you have 3 things you want to try at once and they're not related to each other. Upstream isn't going to change without your understanding, but it's still mechanically something to maintain the rebases on those 3 branches. jj just makes this burden go away.
Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git.
When you make a change to a pr in response to review feedback, do you just jj edit it in, and end up with a force push on GitHub? After which the review comment might get detached from the code or even hidden.
That's definitely something that could be better for me. (That said, there are other projects making it better too.)
Patch-based workflows in general (where you heavily use git rebase -i to curate a smaller set of "perfect" commits for anything you'd PR, rather than just piling new commits onto every PR) don't work well with the GitHub approach, which heavily favors merging stuff through the web interface (making merge or squash commits along the way).
You can make it work of course, but GitHub tends to behave in weird ways when it comes to how it's interface works with patch-based workflows. Perhaps a better estimate would be to see how it compares to a forge like Phorge or Sourcehut.
(The mention of the GitHub SVP being interested in stacked diffs sounds good in that regard. I'm also keeping an eye on Tangled and, now, on ERSC.)
The workflow still functions, it just requires me to manually update bookmarks.
I don't open a PR for each commit, and we use squash commits at work which makes it harder to have this workflow but it still works fine for me.
I rebase only the leaf PR, and I have update-ref enabled to update the branch refs of all other branches in the stack. It works well. The only manual process is that I have to manually force push each branch afterwards.
Lastly, I use the `-x "cargo fmt" -x "cargo clippy"` feature when rebasing (which is missing in jj) to make sure the stack stays in a good state
jj does this for performance reasons. They don't want to perform a full checkout for every rebase action. This is simply something I disagree with
It's true that `jj fix` can be faster by not touching the working copy, but we also want a `jj run` command for the linter feature (https://github.com/jj-vcs/jj/issues/1869). It's just not done yet.
I have a workflow where I have my main and a bunch of branches that are children of other branches. So: main, branch_a, branch_a_1, branch_a_2, branch_a_1_x, etc. Probably not a good workflow, but that's what I do.
I keep editing old commits in my branches to have clean, atomic commits, which fucks up my branch structure and I need to cascade-rebase everything manually.
Do I understand correctly that jj does it automatically?
Same happened e.g. with nodejs getting deno and bun around, which allowed to break nodejs' inertia on many problems that the others have solved.
You can have real branches! Many of them! You don't have to manually merge them! It's decentralized, you can have multiple origins, it lets you work offline! The list goes on and on.
There were many compelling reasons to switch to Git. But for all the articles about jj out there, I've never read any compelling reason to switch to jj. "It easier", "the commands are somewhat more ergonomic"... that's all?
Hot take, but I personally hate git and almost always rely on a GUI tool or IDE integration to interact with it.
It’s very liberating in some ways, in others it’s simply no worse than git. You can do everything you can do with git, but some of those things don’t require multiple steps or n repeats of the same action. jj rebase + commitable conflicts + jj undo = freedom and peace of mind.
I've been exploring JJ mainly for its slightly different approach to change tracking (~every change gets tracked, at least initially, rather than just commits).
Stacked PRs also look interesting but I haven't had an occasion to try them out yet.
But. I think it's incredibly useful for organizations to have patterns for how they use git. There can be huge variance! And there's so many people who don't feel comfortable doing interactive rebases (of their feature branches), or other serious monkeying with history.
(I also think jj's flows are incredibly good about avoiding accidental loss of work in a way that git can be extremely dangerous at.)
I think there's a ton of value to having more of a pattern than the free-form jamming that git gives us. The real value I see in jj is that it's more than the toolbox of things git gives one: it's something more learnable, teachable, and directed than git. And it seems to do it pretty well, with style, and less monkey business. I'm still super greenhorn at jj, and honestly lacking the need for it, but I'm excited to see it come along. Especially since it is compatible with so many other VCS.
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.
I don't see a future for this. I see a series of blog posts that culminate in a tone deaf "What went wrong" finale.
I respect your opinion, but I don't think it's a fact and I couldn't disagree any further with it. I wrote a whole testimonial about why I love jj (first one there): https://jj-vcs.github.io/jj/latest/testimonials/#what-the-us...
> it's impractical for most working programmers to switch
I don't know what you mean here. I think it's quite practical to switch to jj, and people switch over all the time. Some people are going to be earlier adopters than others, but the early adopters can bring others along (as I've been lucky to do at Oxide).
> focus on something whose main appeal is more than social
Steve and I both think that Jujutsu's appeal is far more than merely some bandwagon effect. I do think that social appeal is an important part of making a project succeed, and that projects without substantial technical merit win due to social appeal all the time, but Jujutsu has both! It's amazing!
Thank you for charitably responding to the substance of my comment and especially not whatever tone you may have perceived. I appreciate you.
I know I did. The fact I can use it with git and it doesn’t interfere with any GitHub PR workflows means no-one needs to know I use it. I enjoy the jj model. Maybe you could too, and it’s not a crazy investment of time and energy. It’s an evening playing around with a code kata or something.
Then working with vcs becomes that little bit more enjoyable.
Not a thing in here is true, especially not objectively true. As neutral as you may believe yourself, it might be a good time to step back and reexamine your priors that led you to state so confidently that there’s no usability reason to switch in particular.
The key word I used is "substantial." The usability improvements over Git are marginal and if they ever become non-marginal, they can relatively easily be added to git. This is what my comment is getting at. The only essential difference between Git and JJ is that they are different fiefdoms. There is no substantial technological difference. It's just two different social factions with marginally different opinions about how to type CLI commands.
JJ might produce commits that can be stored in Git, but the affordances are different. If Git wants to adopt them, it becomes no longer Git.
On the other hand, I'm happily using JJ while everyone I collaborate with is using Git. JJ doesn't need to "win" to be useful, it just needs to be useful enough that the people who maintain it continue to maintain it.
Not in my experience. jj is easy to pick up and a joy to use. I like git. I deeply appreciate git. But git can feel like snow shoveling sometimes, while in jj things just click into place.
jj is freeing, because things that were a hassle before are now easy, and other things that were impossible are also easy.
I know there's a lot of hype around for a lot of things, and I get grumpy from all of it. Jujutsu is one of the few things that actually deserve the praise being heaped on them.
You may disagree, of course. But I hope that some day, you'll have reason to be happy about this tool, instead of feeling... whatever touched you off like this.
Yet still, the status quo is not Subversion and SourceForge, both of which have been relegated to antiquity, but git and GitHub.
Will something else unseat git and GitHub in the coming years? And will it be Jujutsu or some other innovation on version control?
Who knows, but I see no need to be so dismissive of somebody’s passion in such an arrogant way.
sounds like someone hasn't used jujutsu
Every magit user disagrees with you.
> and it's impractical for most working programmers to switch
This very much sounds like someone who has never even tried jj. Tell us: What makes switching impractical?
> My well-intentioned recommendation to Steve, because I've been there, is: If you want to avoid feeling like you've wasted your life in a few years on code that doesn't live up to its promise and is essentially no different than the code that already exists in Git (and Hg, Pijul, Fossil, etc.),
Is Steve even a developer for jj?
I am assuming that this new job will change that.
But as we say on Hackernews, there are two kinds of people with respect to jj: those who love it, and those who haven't tried it.
Doing the same thing, but with better usability, is immensely valuable. Remember, Hackernews thought Dropbox was "just" ssh+rsync, but they made a billion dollars making that easy.