3 ms·

I've seen some posts about Jujutsu recently, but I haven't gone deep into specific workflows. Are there specific advantages to using Jujutsu over Emacs Magit?

I've seen some posts about Jujutsu recently, but I haven't gone deep into specific workflows. Are there specific advantages to using Jujutsu over Emacs Magit? All other Git UIs I've used have been severely lacking, but Magit has made me significantly more productive with Git, and has convinced me of the "magic of git". Is Jujutsu interested in competing with this experience? Or is it intended as an alternative to the (to be clear, extremely poor) git user experiences outside of Emacs?

paradox460 1y ago
Jujutsu isn't really a git UI, and in some ways it's rather bad at being one (no support for making tags, submodules, or a few other things) It's a whole new VCS, that just so happens to be backwards compatible with git, and uses git as it's backend Similar to how git brought us cheap branching over svn, JJ brings cheap rebasing. Conflicts are no longer stop the world operations, and you can rebase, rearrange, and manage commits like never before. If you've used tools like stacked diffs before, JJ will feel right at home. Making stacked diff PRs is almost trivial in jj
- jennyholzer 1y ago
  Stacked diffs is a great feature. Thanks for the response!
  - paradox460 1y ago
    No worries. JJ tends to fit modern software engineering a bit better than git, I've found. Here's sort of an example of what I do when I'm working with it I'll open an empty change on top of the main branch, not really sure about where this feature is going to go but knowing that it needs to be new changes. Usually this is already done for me automatically because my main synced with the remote, and therefore is an immutable commit. As I'm writing code I'm not really concerned with how I'm going to commit it to the graph, it's just a big pile of things all changing at the same time. Maybe I do features that are unrelated, or only tangentially related, to the actual story I'm working on. If I get interrupted, I might go over to JJ and describe my changes, typically something along the lines of work in progress with a list of what still needs to be done and what I've been trying to do, basically a capture of my state of mind at the time. I'll then create a new change on top of that, for when I can come back later. Once I'm finished with all of the story and it's working to my satisfaction, I probably have a big ball of changes that need to be split up and organized properly. First thing I do is look at what changes are necessary for this story, which are dependence for it, and which are just things I did because it was convenient to do them at the time. I'll split the dependencies out first putting them into their own changes. Then I'll make the actual story related changes, and then I'll make the ones that are just one offs. With a little bit of rebasing, I now will typically have three or four different bookmarks, which is the JJ analog of branches, some in parallel and some dependent on each other, that I can push up to my remote repository and open up pull requests. I made a couple shell scripts to handle some common things, like recursively splitting a change into parts, but you don't really need them, as they're just wrappers around built in JJ stuff or adaptations to some of my workflows. I touch on them in a blog post that's mostly about JJ: https://pdx.su/blog/2025-08-13-the-quiet-software-tooling-renaissance/ https://pdx.su/blog/2025-08-13-the-quiet-software-tooling-re...
    - nchmy 1y ago
      Glad I'm not the only one who uses it to tidy up the chaos that is my iteration process... I have almost exactly the same workflow. jj just lets me work and not worry AT ALL about commits, vcs etc...
      - paradox460 1y ago
        What's even more interesting is how ally coworkers now know I'm "the guy who can sort out branch complexity" They'll ask me to merge a dozen PRs into a test branch or whatever and it's a piece of cake in jj
- stavros 1y ago
  I use jj, but I haven't gotten into conflicts much yet. What do you mean by "they aren't stop-the-world operations"? I do like how chill jj is about them (as in, it doesn't interrupt what I'm doing), but I always resolve them immediately. Can I not?
  - paradox460 1y ago
    If you're doing a rebase or merge or any other operation, and a conflict comes up, in git you have to resolve it right now, or discard everything. You can't just leave the conflicts in place while you work on something else, they effectively freeze your entire repo. JJ is the opposite. You'll get conflicts, it will tell you about them, but it's up to you to choose when to work on them. You can even keep piling new changes on top of a conflicted one. Your program probably won't work, being full of conflict markers, but you can keep working still
    - stavros 1y ago
      Ahh nice, I didn't realize it'd carry the conflict markers along. That's great, I really like jj.
      - paradox460 1y ago
        You can also resolve the conflict markers in a variety of different styles, not just edit in place. Say I'm doing a dependency update, and someone else updated different dependencies, and our change sets merge. I want both sets of updated versions, but our lockfiles probably conflict, and I don't want to edit them by hand. I can just leave the conflicted lockfiles till the end of the rebase/merge, then purge them and regenerate them using tooling, and then split them up and apply them down to their respective conflicting changes. Sure beats having to toss the lockfile, regen it, then let the rebase continue only to find you have to do it AGAIN
jennyholzer 1y ago
Are there "central concepts" in the Jujutsu design? I'm having a hard time wrapping my mind around what specific details would cause me to choose Jujutsu over Git, in particular because of Git's industry standard status. I think this is a very interesting concept, but I think it could go farther with some more targeted marketing along these lines. Of course, if Git power users are not Jujutsu's intended audience, then this comment may be irrelvant. I think one of Git's great weaknesses is its unfriendliness to newcomers (jargon, deep features, lack of discoverability, lack of accessible GUI frontends), so there's probably a lot of potential for a VC solution that is easier for a newcomer to jump into.
- senekor 1y ago
  > I'm having a hard time wrapping my mind around what specific details would cause me to choose Jujutsu over Git, in particular because of Git's industry standard status. Jujutsu is Git-compatible, so there's nothing to lose. It can literally create the `.git` directory next to the `.jj` directory to fool all your existing tools into thinking this is a git repository. There are a few limitations... Jujutsu currently ignores submodules, for example. So you have to run `git submodule update` sometimes. And when you yourself update the submodule, you need to `git commit` instead of `jj commit`. Git LFS is also not supported. Apart from that, it's smooth sailing AFAIK. > I think this is a very interesting concept, but I think it could go farther with some more targeted marketing along these lines. Of course, if Git power users are not Jujutsu's intended audience, then this comment may be irrelvant. Git power users are definitely part of the target audience, most Jujutsu users today are retired Git power users. Because that's not the target audience of my tutorial though, I didn't write much about that. Some of the features jj users are most excited about include: - Conflicts are non-blocking. Merge and rebase always succeed, conflicts are recorded in the commit itself. You can work on something else and come back later to solve them. - There is `jj undo` and `jj redo` which work like Ctrl[+Shift]+Z in GUI apps and text editors. They affect the whole repository, because that has basically its own linear history. Reflog on steroids, basically. - `jj absorb` can find the most recent commit that touched the same lines and squash your changes into it. It's magical if you're working on several things in parallel (by merging the separate branches together, just for development.) These are just some examples that come up the most in the "appreciation" channel on the Jujutsu discord. > I think one of Git's great weaknesses is its unfriendliness to newcomers (jargon, deep features, lack of discoverability, lack of accessible GUI frontends), so there's probably a lot of potential for a VC solution that is easier for a newcomer to jump into. Yes! I think Jujutsu has a lot of potential there as well. But there's a lack of learning material for that target audience... hence why I wrote this tutorial :-)
nchmy 1y ago
here's a few links that you might find useful. But it would be worth exploring the other recent hn discussions on the topic - i and other unabashed evangelists have shared a lot. A great "Megamerge" workflow https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj... https://ofcr.se/jujutsu-merge-workflow https://ofcr.se/jujutsu-merge-workflow And an absolutely fantastic TUI that wraps jj cli. Might be the best TUI ive ever used, and consistently getting better. https://github.com/idursun/jjui https://github.com/idursun/jjui
veqq 1y ago
jj is similar to a magit cli, brought to the rest of the world. There's no benefit to switching from magit.
wry_discontent 1y ago
I switched from Magit to jujutsu. The only difference for me is that stacking PRs has become simpler. It's also made me more conscious of making smaller changes and shrinking what I consider "worth shipping". Overall a positive experience, but if Magit is working for you, there's no killer feature that makes it worthwhile. I'm also using https://github.com/bolivier/jj-mode.el https://github.com/bolivier/jj-mode.el which lets me do enough of what I need with jj from within Emacs.
- trueismywork 1y ago
  How do you incrementally resolve merge conflicts in magit?
  - wry_discontent 1y ago
    I don't know what that means. I haven't changed how I resolve conflicts with jj.
aseipp 1y ago
If you are already a heavy Magit user, then most of the basic ideas will probably be appealing and jj will let you bring those ideas to the command line. It will let you do some acrobatics you thought weren't possible before, ones that many users have come to love -- like rebasing a 5-way octopus merge with 2 extra leaves that result in conflicts you don't have to solve yet. (This is a technique known and popularized as "Mega Merge", which I suppose I am responsible for "inventing" along with its semi-silly name.) I think Magit is an interesting parallel to jj. You say the "magic of git", but for both of them I think most of the "magic" has less to do with Git and more to do with the "design language" exposed to users, and by that I mean the tools that allow you to manipulate, navigate, and arrange commits (and diffs!) Git is more like a physical storage layer for both Magit and jj, but beyond that a lot of the special sauce is unique to their algorithms, their UX, and their "nouns and verbs". In my experience, Magit users are generally harder to sell because for them jj isn't so revolutionary; die-hard Git powerusers who have been exclusively slugging it out on the command line to perform 10-stack rebases for the last 5+ years tend to be very easy to sell, in comparison. But all these users tend to understand and appreciate the power of a well-designed set of tools for commit graph manipulation. Git powerusers tend to be some of our most hardcore converts and advocates, really. Full disclosure but I'm one of the jj maintainers and my opinion is that it's pretty good. Maybe try it out for a few days (perhaps without using Magit, if you can :)
- skydhash 1y ago
  I think git was meant to be used as a base layer. You design your workflow and then add you aliases on top, making it more semantically significant for you.
arialdomartini 1y ago
You will be probably excited to give https://github.com/bolivier/jj-mode.el https://github.com/bolivier/jj-mode.el a try.

paradox460 1y ago

Jujutsu isn't really a git UI, and in some ways it's rather bad at being one (no support for making tags, submodules, or a few other things) It's a whole new VCS, that just so happens to be backwards compatible with git, and uses git as it's backend Similar to how git brought us cheap branching over svn, JJ brings cheap rebasing. Conflicts are no longer stop the world operations, and you can rebase, rearrange, and manage commits like never before. If you've used tools like stacked diffs before, JJ will feel right at home. Making stacked diff PRs is almost trivial in jj

jennyholzer 1y ago
Stacked diffs is a great feature. Thanks for the response!
- paradox460 1y ago
  No worries. JJ tends to fit modern software engineering a bit better than git, I've found. Here's sort of an example of what I do when I'm working with it I'll open an empty change on top of the main branch, not really sure about where this feature is going to go but knowing that it needs to be new changes. Usually this is already done for me automatically because my main synced with the remote, and therefore is an immutable commit. As I'm writing code I'm not really concerned with how I'm going to commit it to the graph, it's just a big pile of things all changing at the same time. Maybe I do features that are unrelated, or only tangentially related, to the actual story I'm working on. If I get interrupted, I might go over to JJ and describe my changes, typically something along the lines of work in progress with a list of what still needs to be done and what I've been trying to do, basically a capture of my state of mind at the time. I'll then create a new change on top of that, for when I can come back later. Once I'm finished with all of the story and it's working to my satisfaction, I probably have a big ball of changes that need to be split up and organized properly. First thing I do is look at what changes are necessary for this story, which are dependence for it, and which are just things I did because it was convenient to do them at the time. I'll split the dependencies out first putting them into their own changes. Then I'll make the actual story related changes, and then I'll make the ones that are just one offs. With a little bit of rebasing, I now will typically have three or four different bookmarks, which is the JJ analog of branches, some in parallel and some dependent on each other, that I can push up to my remote repository and open up pull requests. I made a couple shell scripts to handle some common things, like recursively splitting a change into parts, but you don't really need them, as they're just wrappers around built in JJ stuff or adaptations to some of my workflows. I touch on them in a blog post that's mostly about JJ: https://pdx.su/blog/2025-08-13-the-quiet-software-tooling-renaissance/ https://pdx.su/blog/2025-08-13-the-quiet-software-tooling-re...
  - nchmy 1y ago
    Glad I'm not the only one who uses it to tidy up the chaos that is my iteration process... I have almost exactly the same workflow. jj just lets me work and not worry AT ALL about commits, vcs etc...
    - paradox460 1y ago
      What's even more interesting is how ally coworkers now know I'm "the guy who can sort out branch complexity" They'll ask me to merge a dozen PRs into a test branch or whatever and it's a piece of cake in jj
stavros 1y ago
I use jj, but I haven't gotten into conflicts much yet. What do you mean by "they aren't stop-the-world operations"? I do like how chill jj is about them (as in, it doesn't interrupt what I'm doing), but I always resolve them immediately. Can I not?
- paradox460 1y ago
  If you're doing a rebase or merge or any other operation, and a conflict comes up, in git you have to resolve it right now, or discard everything. You can't just leave the conflicts in place while you work on something else, they effectively freeze your entire repo. JJ is the opposite. You'll get conflicts, it will tell you about them, but it's up to you to choose when to work on them. You can even keep piling new changes on top of a conflicted one. Your program probably won't work, being full of conflict markers, but you can keep working still
  - stavros 1y ago
    Ahh nice, I didn't realize it'd carry the conflict markers along. That's great, I really like jj.
    - paradox460 1y ago
      You can also resolve the conflict markers in a variety of different styles, not just edit in place. Say I'm doing a dependency update, and someone else updated different dependencies, and our change sets merge. I want both sets of updated versions, but our lockfiles probably conflict, and I don't want to edit them by hand. I can just leave the conflicted lockfiles till the end of the rebase/merge, then purge them and regenerate them using tooling, and then split them up and apply them down to their respective conflicting changes. Sure beats having to toss the lockfile, regen it, then let the rebase continue only to find you have to do it AGAIN

jennyholzer 1y ago

Are there "central concepts" in the Jujutsu design? I'm having a hard time wrapping my mind around what specific details would cause me to choose Jujutsu over Git, in particular because of Git's industry standard status. I think this is a very interesting concept, but I think it could go farther with some more targeted marketing along these lines. Of course, if Git power users are not Jujutsu's intended audience, then this comment may be irrelvant. I think one of Git's great weaknesses is its unfriendliness to newcomers (jargon, deep features, lack of discoverability, lack of accessible GUI frontends), so there's probably a lot of potential for a VC solution that is easier for a newcomer to jump into.

senekor 1y ago
> I'm having a hard time wrapping my mind around what specific details would cause me to choose Jujutsu over Git, in particular because of Git's industry standard status. Jujutsu is Git-compatible, so there's nothing to lose. It can literally create the `.git` directory next to the `.jj` directory to fool all your existing tools into thinking this is a git repository. There are a few limitations... Jujutsu currently ignores submodules, for example. So you have to run `git submodule update` sometimes. And when you yourself update the submodule, you need to `git commit` instead of `jj commit`. Git LFS is also not supported. Apart from that, it's smooth sailing AFAIK. > I think this is a very interesting concept, but I think it could go farther with some more targeted marketing along these lines. Of course, if Git power users are not Jujutsu's intended audience, then this comment may be irrelvant. Git power users are definitely part of the target audience, most Jujutsu users today are retired Git power users. Because that's not the target audience of my tutorial though, I didn't write much about that. Some of the features jj users are most excited about include: - Conflicts are non-blocking. Merge and rebase always succeed, conflicts are recorded in the commit itself. You can work on something else and come back later to solve them. - There is `jj undo` and `jj redo` which work like Ctrl[+Shift]+Z in GUI apps and text editors. They affect the whole repository, because that has basically its own linear history. Reflog on steroids, basically. - `jj absorb` can find the most recent commit that touched the same lines and squash your changes into it. It's magical if you're working on several things in parallel (by merging the separate branches together, just for development.) These are just some examples that come up the most in the "appreciation" channel on the Jujutsu discord. > I think one of Git's great weaknesses is its unfriendliness to newcomers (jargon, deep features, lack of discoverability, lack of accessible GUI frontends), so there's probably a lot of potential for a VC solution that is easier for a newcomer to jump into. Yes! I think Jujutsu has a lot of potential there as well. But there's a lack of learning material for that target audience... hence why I wrote this tutorial :-)

nchmy 1y ago

here's a few links that you might find useful. But it would be worth exploring the other recent hn discussions on the topic - i and other unabashed evangelists have shared a lot. A great "Megamerge" workflow https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj... https://ofcr.se/jujutsu-merge-workflow https://ofcr.se/jujutsu-merge-workflow And an absolutely fantastic TUI that wraps jj cli. Might be the best TUI ive ever used, and consistently getting better. https://github.com/idursun/jjui https://github.com/idursun/jjui

veqq 1y ago

jj is similar to a magit cli, brought to the rest of the world. There's no benefit to switching from magit.

wry_discontent 1y ago

I switched from Magit to jujutsu. The only difference for me is that stacking PRs has become simpler. It's also made me more conscious of making smaller changes and shrinking what I consider "worth shipping". Overall a positive experience, but if Magit is working for you, there's no killer feature that makes it worthwhile. I'm also using https://github.com/bolivier/jj-mode.el https://github.com/bolivier/jj-mode.el which lets me do enough of what I need with jj from within Emacs.

trueismywork 1y ago
How do you incrementally resolve merge conflicts in magit?
- wry_discontent 1y ago
  I don't know what that means. I haven't changed how I resolve conflicts with jj.

aseipp 1y ago

If you are already a heavy Magit user, then most of the basic ideas will probably be appealing and jj will let you bring those ideas to the command line. It will let you do some acrobatics you thought weren't possible before, ones that many users have come to love -- like rebasing a 5-way octopus merge with 2 extra leaves that result in conflicts you don't have to solve yet. (This is a technique known and popularized as "Mega Merge", which I suppose I am responsible for "inventing" along with its semi-silly name.) I think Magit is an interesting parallel to jj. You say the "magic of git", but for both of them I think most of the "magic" has less to do with Git and more to do with the "design language" exposed to users, and by that I mean the tools that allow you to manipulate, navigate, and arrange commits (and diffs!) Git is more like a physical storage layer for both Magit and jj, but beyond that a lot of the special sauce is unique to their algorithms, their UX, and their "nouns and verbs". In my experience, Magit users are generally harder to sell because for them jj isn't so revolutionary; die-hard Git powerusers who have been exclusively slugging it out on the command line to perform 10-stack rebases for the last 5+ years tend to be very easy to sell, in comparison. But all these users tend to understand and appreciate the power of a well-designed set of tools for commit graph manipulation. Git powerusers tend to be some of our most hardcore converts and advocates, really. Full disclosure but I'm one of the jj maintainers and my opinion is that it's pretty good. Maybe try it out for a few days (perhaps without using Magit, if you can :)

skydhash 1y ago
I think git was meant to be used as a base layer. You design your workflow and then add you aliases on top, making it more semantically significant for you.

arialdomartini 1y ago

You will be probably excited to give https://github.com/bolivier/jj-mode.el https://github.com/bolivier/jj-mode.el a try.