Trying out jj is super low-risk--since it uses git as a backend, you can test it out and bail back to git without any drawbacks other than a detached head state.
And I hope you do. It is so much better than git in every way. It enables working with stacks and the aforementioned megamerges so easily, allowing me to continue working forward while smaller units of work are reviewed/merged.
When I first tried to use jj, I wasn't entirely committed and switched between jj and git. Finally I hit a breaking point being fed up with stacks/merges and tried jj _for real_.
I recommend to give it a serious try for a few solid days and use it exclusively to really understand it. You won't go back.
The jj Discord is a very helpful place. Thanks to everyone there. Great article Isaac!
> Trying out jj is super low-risk--since it uses git as a backend, you can test it out and bail back to git without any drawbacks other than a detached head state.
Btw, the risk of trying out other modern version control systems is nearly as low: most of them are compatible with git and you can convert back and forth. That definitely includes mercurial etc.
I’ve been loving it for personal projects. But for work, some of our homebrew tooling relies heavily on hashes. So any operation that causes snapshotting to occur tends to lead to breakage that utterly confounds Claude. I tried giving it rules and instructions to make sure to sync git up to the correct commit for the current snapshot, but as soon as the signal for that is too week in the context it blows a gasket trying to figure out what has gone wrong.
I reluctantly stopped using mercurial 10 or so years ago, and reading this brings a little tear to my eye. Mercurial was just about where jj seems to be now. It had revsets. It had just gotten the concept of mutable and immutable commits. It had absorb. It had bookmarks. It never had an "index". The commands had human readable options like I see in this post. It could work with git repositories. Man I miss it.
I'm hesitant to pick jj up in case it ends up losing to git like mercurial did. But it's very tempting.
I don't get JJ. Every time it's posted people gush about how JJ enables some super complicated workflow that I can't wrap my head around. I have a simple feature branch/rebase workflow in git that has served me well for decades so I guess I don't understand why I would want to complicate things with (in this case) an "octopus merge/megamerge". Wouldn't that make it more difficult to reason about the repository/history?
If you wrangle a lot of in flight changes that are not yet merged into your teams primary git repo, it's very helpful. I have some 10-30 changes in various states at any time. Sometimes they have dependencies on each other sometimes they don't. Placing them all into one branch can work but it's a lot less ergonomic in many ways. jj makes my life simpler because it accommodates my workflow in a way git doesn't.
Honestly, if you don't find it appealing you don't need to use it. I think a lot of folks don't find vim appealing and stick to vscode and that's okay too.
Every time I hear about this megamerge and stacked pr nonsense, it just smells to me. Like, why does your engineering organization have a culture where this sort of nonsense is required in the first place? Anytime I see articles like this gushing about how great tool XYZ is for stack merging and things like that, all I hear is "you don't have a culture where you can get someone looking at and mainlining your PR on the same day"
The jj lovers can go build their massive beautiful branches off in a corner, I'll be over here building an SDLC that doesn't require that.
It depends. We have pretty good review culture (usually same day rarely more than 24H), but some changes may need multiple rounds of review or might be have flaky tests that uncovers after a few hours. Also some work is experimental and not ready for pushing out for review. Sometimes I create a very large number of commits as part of a migration DND I can't get them all reviewed in parallel. It can be a lot of things. Maybe it happens more with monorepos.
Semi off-topic, but does anyone know of good resources for jj that don't assume git knowledge? Steve's and others are high quality, but often things are explained in terms of git equivalents or describe workflows that I struggle to fully understand the purpose of, as someone who knows only the barest basics of git necessary to work on personal projects.
If none exist, I think there's a great opportunity there, for anyone with the knowledge and motivation to make some absolute beginner guides. Already jj is infinitely more user-friendly, and as the tool matures, it isn't far fetched to think a new generation of programmers could go straight to jj without knowing their way around git first.
I'm not immediately aware. There's a certain amount of git-ness embedded in it with it being a DAG, having commits, and being compatible with git remotes. And, since the industry still runs on git, most people will need to learn it somewhat, anyway.
Been trying to get into jj lately, but I rely a lot on VS Code's git gutter to review changes as I code. Doesn't look like jj has an equivalent in VS Code. Anyone got tool recommendations?
I just use the VS Code git integration with the jj colocated git repo. HEAD is @- and the changes in @ are considered working copy changes. It works for all I was using the VS Code integration for.
I have a PR up for jjk that does the full change as a review changes, and there's another user's PR that allows diffs over arbitrary ranges (i.e. when working out whether the commits that make up a PR are good as a whole rather than individually)
You are not actually working in parallel. You are making the cost of stopping one thing near zero. In git, pausing A for B costs a rebase. In jj, you edit B, the stack reflows, you keep going. That is the whole thing. Context switches get cheap so you take them.
Great writeup! I've been using `jj parallelize` [1] a lot (and wrote about it here [2]) to fan out a sequence of commits to set up a megamerge, but your stack alias sounds super useful to create them on the fly, rather than at the very end of a work stream. Thanks for the tips!
Makes me happy to see the influx of jj posts as of late. Great tool. Roughly this workflow is how I convinced a few friends to finally loosen their death grip on git and try something new.
I was skeptical at first but when I dragged and dropped a bookmark in `gg` then a light went on in my head. Also the fact that jujutsu does everything in "detached mode" locally means that you can't mess up your remote git repo (unless you force push all yolo from git itself, but you're never expected to do that).
I do not understand the appeal of the workflow of working on separate things in parallel, then splitting it off into branches/commits. imo, isn't it better to fully focus on one thing at a time, even if it is "simple"?
I imagine if I follow this workflow, I might accidentally split it off in a way that branch A is dependent on some code changes in branch B, and/or vice versa. Or I might accidentally split it off in a way that makes it uncompilable (or introduce a subtle bug) in one commit/branch because I accidentally forgot there was a dependency on some code that was split off somewhere else. Of course, the CI/CD pipeline/reviewers/self-testing can catch this, but this all seems to introduce a lot of extra work when I could have just been working on things one at a time.
I'm open to changing my mind, I'm sure there are lots of benefits to this approach, since it is popular. What am I missing here?
From practical experience from using jj daily and having (disposable) mega merges:
When I have discrete, separate units of work, but some may not merge soon (or ever), being able to use mega merges is so amazing.
For example, I have some branch that has an experimental mock-data-pipeline thingy. I have yet to devote the time to convince my colleagues to merge it. But I use it.
Meanwhile, I could be working on two distinct things that can merge separately, but I would like to use Thing A while also testing Thing B, but ALSO have my experimental things merged in.
Simply run `jj new A B C`. Now I have it all.
Because jj's conflict resolution is fundamentally better, and rebases are painless, this workflow is natural and simple to use as a tool
I had a big feature I was working on. jj made it easy to split it into 21 small commits so I could give reviewers smaller things to review while I continued to work. It wasn't perfect and maybe git can do it all by itself but it's not my experience.
In other words, I effectively was working on one thing, but at a quicker easier pace.
I’ve found megamerge really helpful in cases where I’m working on a change that touches multiple subsystems. As an example, imagine a feature where a backend change supports a web change and a mobile change. I want all three changes in place locally for testing and development, but if I put them in the same PR, it becomes too hard to review—maybe mobile people don’t want to vouch for the web changes.
You’re right that I have to make sure that the backend changes don’t depend on the mobile changes, but I might have to be mindful of this anyway if the backend needs to stay compatible with old mobile app versions. Megamerge doesn’t seem to make it any harder.
I don't think I really understand the way jujutsu is doing this, but if it's what I think, one example would be that you realize while working that some changeset is getting too big and makes sense to split it. So B would depend on A and be on top eventually, but you don't know the final form of B until you've finished with both. I've always just done this with rebasing and fixups, but I could see it being easier if you could skip that intermediate step.
It does seem to introduce a lot of complexity for its own sake. This kind of workflow only survives on the absorb command and like you said it doesn't really cover all the interplay of changes when separated. It's a more independent version of stacked diffs, with worse conceptual complexity.
>I do not understand the appeal of the workflow of working on separate things in parallel, then splitting it off into branches/commits. imo, isn't it better to fully focus on one thing at a time, even if it is "simple"?
because agents are slow.
I use SOTA model (latest opus/chatgpt) to first flesh out all the work. since a lot of agent harness use some black magic, i use this workflow
1. Collect all issues
2. Make a folder
3. Write each issue as a file with complete implementation plan to rectify the issue
After this, i change from SOTA to Mini model
Loop through each issue or run agents in parallel to implement 1 issue at a time.
I usually need to do 3 iteration runs to implement full functionality.
Sometimes you want to work on something and as a prerequisite that needs X. Then you realise once X is in place you can actually build a number of useful things against X. And so forth. There’s no good way to merge sequentially, other then a multi merge
As a jujutsu user, I don't disagree. I can see the appeal of doing a megamerge, but routinely working on the megamerged version and then moving the commits to the appropriate branch would be the exception, not the norm.
I gather one scenario is: You do a megamerge and run all your tests to make sure new stuff in one branch isn't breaking new stuff in another branch. If it does fail, you do your debug and make your fix and then squash the fix to the appropriate branch.
I wouldn't do it this exact way either but the benefit is "having any local throwaway integration branch" vs. having none at all. You don't need to do it this exact way to have one.
>The absorb command will do a lot of this for you by identifying which downstream mutable commit each line or hunk of your current commit belong in and automatically squashing them down for you. This feels like magic every time I use it (and not the evil black box black magic kind of magic where nothing can be understood), and it’s one of the core pieces of Jujutsu’s functionality that make the megamerge workflow so seamless.
"Evil" merged are only evil if your tooling skips over merge commits as "unimportant" which is a common tactic to try and prune some of the crazy trees you get when hundreds of people are making merge commits into a repo which then creates its own commits for automation reasons...
I found octopus megamerge hard to collaborate - my colleagues don't use JJ so they may introduce changes that would cause conflitcts to my megamerge. When you have a conflict on a change that has more than 2 parents, the conflict resolution becomes unmanageable very quickly. No merge tool can handle more than 3-way merge, so you have to do that manually.
Eventually I settled on a tree-like megamerge that's more practical: merge 2 branches at a time and merge the merged branch with the next branch. This way I only need to handle 2-way conflicts at a time which is more manageable.
Also you have to be very careful to decide the order when you (and your colleagues) are going to land the branches, or if you expect any new features other people are working on that's going to conflict with your branches. When using megamerger workflow, most of the problems come from coordinating with other colleagues.
I love this stuff as a hobbyist, but professionally I can't help but think this is all obsolete in the age of agent-driven development. I wish jj was around a decade ago.
I've been playing around with agent-native source annotation to specifically address the massively parallel work problem. Check it out here: https://github.com/draxl-org/draxl
You don’t need jj for this anymore. The whole premise of optimizing human workflows around source control is becoming obsolete.
When LLMs are driving development, source control stops being an active cognitive concern and becomes a passive implementation detail. The unit of work is no longer “branches” or “commits,” it’s intent. You describe what you want, the model generates, refactors, and reconciles changes across parallel streams automatically.
Parallel workstreams used to require careful coordination: rebasing, merging, conflict resolution, mental bookkeeping of state. That overhead existed because humans were the bottleneck. Once an LLM is managing the codebase, it can reason over the entire state space continuously and resolve those conflicts as part of generation, not as a separate step.
In that world, tools like jj are optimizing a layer that’s already being abstracted away. It’s similar to how no one optimizes around assembly anymore. It still exists, it still matters at a lower level, but it’s no longer where productivity is gained.
> The unit of work is no longer “branches” or “commits,”
It better be, now and going forward for people who use LLMs..because they will need it when LLM messes up and have to figure out, manually, how to resolve.
You ll need all the help (not to mention luck) you need then..
There are a lot of assumptions baked into your assessment. We are not at the point where manual workflows are obsolete. Maybe it is for folks who work on web apps, but it's certainly not the case for many others. AI Agents are constantly making mistakes and need oversight. Things have gotten dramatically better, but not enough for me to trust it to not create a terrible mess.
A lot of words to say "LLMs are good for this, trust me bro!"
You're bashing the old way, but you do not provide any concrete evidence for any of your points.
> The unit of work is no longer “branches” or “commits,” it’s intent.
Insert <astronaut meme "always has been">.
Branching is always about "I want to try to implement this thing, but I also want to quickly go back to the main task/canonical version". Committing is about I want to store this version in time with a description of the changes I made since the last commit. So both are an expression and a record of intent.
> Parallel workstreams used to require careful coordination: rebasing, merging, conflict resolution, mental bookkeeping of state.
Your choice of words is making me believe that you have a poor understanding of version control and only see it as storage of code.
Commits are notes that annotates changes, when you want to share your work, you share the changes since the last version everyone knows about alongside the notes that (should) explain those changes. But just like you take time to organize and edit your working notes for a final piece, rebasing is how you edit commits to have a cleaner history. Merging is when you want to keep the history of two branches.
Conflict resolution is a nice signal that the intent of a section of code may differ (eg. one wants blue, the other wants red). Having no conflict is not a guarantee that the code works (one reduces the size of the container, while the other increase the flow of the pipe, both wanted to speed up filling the container). So you have to inspect the code and run test afterwards.
Discard the above if you just don't care about the code that you're writing.
Actually it’s more relevant than ever since agents trivially parallelize work, but it still needs to be validated together. You can work on individual branches in worktrees and have the ‘megamerge’ in yet another.
I have been using Claude for 95% of the mechanical coding for months, and jj has proven to be more relevant than not for me. Because it is a better VCS tool than git, it allows to work with the firehose of commits much more seamlessly.
This is something you have to generally handle manually since absorb won't squash hunks with ambiguous targets, but I typically stack these branches and accept the dependency. I have had instances where this has backfired a little bit re: ordering but thankfully with JJ and the very patient little man in my computer named Codex it's easy to reorder them and end up with the same diff
The mega merge wouldn't handle that based on the way the article shows. You COULD have a revset that includes stacked changes, though. That does work and is what I currently do.
It's interesting to see the strange workflows that come from jujutsu users, as someone who works on git workflows.
There's some counterproductive stuff in there from my perspective but at its core you're keeping up a throwaway integration branch, which is helpful practice if you'll ever care about an integration. It's annoying with git because the interface for updating your throwaway integration branch is very clunky and easy to get wrong.
I saw Jujutsu on HN a few days ago and gave it a try. I picked a bunch of it up in just a couple hours and a couple days later I've completely switched to it for all my projects, it's not even close. Git is dead to me.
I just wish Jujutsu supported git tags rather than only supporting bookmarks as branches. And I also wish that Jujutsu supported preserving commit dates during rebases.
One of my absolute favorite things about Jujutsu is how easy it is to manipulate the commit graph remotely without having to manually checkout each commit first. I've been working on some pull requests to their built-in diff editor lately trying to improve the user experience enough that most conflicts will be fixable without having to use a text editor.
Also, the lack of a special staging area means you also never have to fucking stash your changes before you can do practically anything. Your changes always have a place, you can always go somewhere else and you can always come back.
Oh? That's incredibly recent. Thank you for letting me know. As it turns out, I just built jj from source earlier today, so ironically I should already have tags. I'll give it a try.
Re: commit dates, fundamentally those always change when rebasing because you're rewriting the commit object, but we don't touch the author date unless you explicitly reset it with metaedit
Same here, picked it up a week ago and haven’t touched git again.
Probably my favourite thing that has really changed my workflow is being able to write empty commits in advance then just switch between them. It helps me remember what I’m doing and whats next whenever I get distracted or take a break.
And I hope you do. It is so much better than git in every way. It enables working with stacks and the aforementioned megamerges so easily, allowing me to continue working forward while smaller units of work are reviewed/merged.
When I first tried to use jj, I wasn't entirely committed and switched between jj and git. Finally I hit a breaking point being fed up with stacks/merges and tried jj _for real_.
I recommend to give it a serious try for a few solid days and use it exclusively to really understand it. You won't go back.
The jj Discord is a very helpful place. Thanks to everyone there. Great article Isaac!
Btw, the risk of trying out other modern version control systems is nearly as low: most of them are compatible with git and you can convert back and forth. That definitely includes mercurial etc.
I'm hesitant to pick jj up in case it ends up losing to git like mercurial did. But it's very tempting.
Honestly, if you don't find it appealing you don't need to use it. I think a lot of folks don't find vim appealing and stick to vscode and that's okay too.
The jj lovers can go build their massive beautiful branches off in a corner, I'll be over here building an SDLC that doesn't require that.
Old man yells at cloud moment is over
Though, I'd be remiss not to mention that this (and any other) jj workflow would be much easier with jjui. It's the best TUI around, not just for jj
I proposed incorporating some of this article into it. https://github.com/idursun/jjui/discussions/644
If none exist, I think there's a great opportunity there, for anyone with the knowledge and motivation to make some absolute beginner guides. Already jj is infinitely more user-friendly, and as the tool matures, it isn't far fetched to think a new generation of programmers could go straight to jj without knowing their way around git first.
https://github.com/anthrofract/majjit
https://www.visualjj.com/
https://github.com/keanemind/jjk
what's next, "oh! my gitess"? "chainsvn man"?
I have a PR up for jjk that does the full change as a review changes, and there's another user's PR that allows diffs over arbitrary ranges (i.e. when working out whether the commits that make up a PR are good as a whole rather than individually)
[1] https://docs.jj-vcs.dev/latest/cli-reference/#jj-parallelize [2] https://blog.chay.dev/parallelized-commits
If anyone is JJ-curious, I also can't recommend the Discord[1] enough. The community is very helpful and welcoming.
[1]: https://discord.com/invite/dkmfj3aGQN
I imagine if I follow this workflow, I might accidentally split it off in a way that branch A is dependent on some code changes in branch B, and/or vice versa. Or I might accidentally split it off in a way that makes it uncompilable (or introduce a subtle bug) in one commit/branch because I accidentally forgot there was a dependency on some code that was split off somewhere else. Of course, the CI/CD pipeline/reviewers/self-testing can catch this, but this all seems to introduce a lot of extra work when I could have just been working on things one at a time.
I'm open to changing my mind, I'm sure there are lots of benefits to this approach, since it is popular. What am I missing here?
When I have discrete, separate units of work, but some may not merge soon (or ever), being able to use mega merges is so amazing.
For example, I have some branch that has an experimental mock-data-pipeline thingy. I have yet to devote the time to convince my colleagues to merge it. But I use it.
Meanwhile, I could be working on two distinct things that can merge separately, but I would like to use Thing A while also testing Thing B, but ALSO have my experimental things merged in.
Simply run `jj new A B C`. Now I have it all.
Because jj's conflict resolution is fundamentally better, and rebases are painless, this workflow is natural and simple to use as a tool
In other words, I effectively was working on one thing, but at a quicker easier pace.
You’re right that I have to make sure that the backend changes don’t depend on the mobile changes, but I might have to be mindful of this anyway if the backend needs to stay compatible with old mobile app versions. Megamerge doesn’t seem to make it any harder.
because agents are slow.
I use SOTA model (latest opus/chatgpt) to first flesh out all the work. since a lot of agent harness use some black magic, i use this workflow
1. Collect all issues 2. Make a folder 3. Write each issue as a file with complete implementation plan to rectify the issue
After this, i change from SOTA to Mini model
Loop through each issue or run agents in parallel to implement 1 issue at a time.
I usually need to do 3 iteration runs to implement full functionality.
I gather one scenario is: You do a megamerge and run all your tests to make sure new stuff in one branch isn't breaking new stuff in another branch. If it does fail, you do your debug and make your fix and then squash the fix to the appropriate branch.
IUUC This is already implemented for git as an extension. https://github.com/tummychow/git-absorb
I think this is such a basic thing that should be part of any DVCS implementation.
Eventually I settled on a tree-like megamerge that's more practical: merge 2 branches at a time and merge the merged branch with the next branch. This way I only need to handle 2-way conflicts at a time which is more manageable.
Also you have to be very careful to decide the order when you (and your colleagues) are going to land the branches, or if you expect any new features other people are working on that's going to conflict with your branches. When using megamerger workflow, most of the problems come from coordinating with other colleagues.
When LLMs are driving development, source control stops being an active cognitive concern and becomes a passive implementation detail. The unit of work is no longer “branches” or “commits,” it’s intent. You describe what you want, the model generates, refactors, and reconciles changes across parallel streams automatically.
Parallel workstreams used to require careful coordination: rebasing, merging, conflict resolution, mental bookkeeping of state. That overhead existed because humans were the bottleneck. Once an LLM is managing the codebase, it can reason over the entire state space continuously and resolve those conflicts as part of generation, not as a separate step.
In that world, tools like jj are optimizing a layer that’s already being abstracted away. It’s similar to how no one optimizes around assembly anymore. It still exists, it still matters at a lower level, but it’s no longer where productivity is gained.
It better be, now and going forward for people who use LLMs..because they will need it when LLM messes up and have to figure out, manually, how to resolve.
You ll need all the help (not to mention luck) you need then..
You're bashing the old way, but you do not provide any concrete evidence for any of your points.
> The unit of work is no longer “branches” or “commits,” it’s intent.
Insert <astronaut meme "always has been">.
Branching is always about "I want to try to implement this thing, but I also want to quickly go back to the main task/canonical version". Committing is about I want to store this version in time with a description of the changes I made since the last commit. So both are an expression and a record of intent.
> Parallel workstreams used to require careful coordination: rebasing, merging, conflict resolution, mental bookkeeping of state.
Your choice of words is making me believe that you have a poor understanding of version control and only see it as storage of code.
Commits are notes that annotates changes, when you want to share your work, you share the changes since the last version everyone knows about alongside the notes that (should) explain those changes. But just like you take time to organize and edit your working notes for a final piece, rebasing is how you edit commits to have a cleaner history. Merging is when you want to keep the history of two branches.
Conflict resolution is a nice signal that the intent of a section of code may differ (eg. one wants blue, the other wants red). Having no conflict is not a guarantee that the code works (one reduces the size of the container, while the other increase the flow of the pipe, both wanted to speed up filling the container). So you have to inspect the code and run test afterwards.
Discard the above if you just don't care about the code that you're writing.
I'm still not as smooth at figuring out conflicts on mega-rebase.
There's some counterproductive stuff in there from my perspective but at its core you're keeping up a throwaway integration branch, which is helpful practice if you'll ever care about an integration. It's annoying with git because the interface for updating your throwaway integration branch is very clunky and easy to get wrong.
I just wish Jujutsu supported git tags rather than only supporting bookmarks as branches. And I also wish that Jujutsu supported preserving commit dates during rebases.
One of my absolute favorite things about Jujutsu is how easy it is to manipulate the commit graph remotely without having to manually checkout each commit first. I've been working on some pull requests to their built-in diff editor lately trying to improve the user experience enough that most conflicts will be fixable without having to use a text editor.
Also, the lack of a special staging area means you also never have to fucking stash your changes before you can do practically anything. Your changes always have a place, you can always go somewhere else and you can always come back.
There are commands for manipulating tags (jj tag set, jj tag delete), and recently [1] support for fetching / pushing
[1]: https://github.com/jj-vcs/jj/pull/9279
Probably my favourite thing that has really changed my workflow is being able to write empty commits in advance then just switch between them. It helps me remember what I’m doing and whats next whenever I get distracted or take a break.