30 ms·

Jujutsu for busy devs

383 points by Bogdanp 1y ago

accelbred 1y ago
Is there a magit equivalent? I heavily use magit's interactive features and extensions to the git UI (like spinoff, absorb, or the auto-backup thing)
- stouset 1y ago
  I am not a magit user but from doing a little bit of reading, all of these commands are essentially first-class citizens in jj. Spinoff seems to be `jj split` (or in most cases literally nothing because the default is to edit a new, empty revision off the trunk), absorb is probably `jj rebase` or `jj squash`, and the auto-backup is either the evolog (which tracks file changes that haven't been explicitly commmited) or the op log (which lets you reset the entire repo to what it looked like before or after any operation). There is also lazyjj as an interactive UI.
  - Filligree 1y ago
    magit-merge-absorb is one of rebase (if that's what you want), or new (which gets you a merge when you specify multiple parents). The 'delete the branch' part of it doesn't really apply, because jj doesn't have branches; though you might need to delete a tag. Note for other readers: jj also has a literal `jj absorb` command. That one does what you'd expect from mercurial, i.e. moves diffs from the current commit into the most recent ancestral commit where that file was changed.
    - stouset 1y ago
      Note also that jj does have branches, they are just anonymous. You don't checkout a branch or edit a branch, you edit a revision or make a new one. One revision with multiple children is a branching point, one revision with multiple parents is a merge. You name them with bookmarks which are sort of like branch names except they don't follow along automatically as you make new revisions. You can point an existing bookmark at a later revision when you're ready to push new changes.
- do_not_redeem 1y ago
  jjui is the best VCS TUI I've ever used. It's even smoother than magit, but I think most of that is because of jj itself. Spinoff and absorb are both native jj features (jj rebase and jj absorb, respectively) https://github.com/idursun/jjui https://github.com/idursun/jjui
  - tcoff91 1y ago
    I’ve got to check this out. I’ve really been loving these two neovim JJ plugins For splitting commits: https://github.com/julienvincent/hunk.nvim https://github.com/julienvincent/hunk.nvim For resolving conflicts: https://github.com/rafikdraoui/jj-diffconflicts https://github.com/rafikdraoui/jj-diffconflicts
  - nchmy 1y ago
    Completely agreed. I've been evangelizing jjui even more than I do jj! And, you're right, it's powers largely come from the underlying jj - it mostly just runs jj commands behind the scenes, parses the output, and displays it. But it's all so beautiful, seamless etc.. I can't wait to really dig into the big additions released yesterday in v0.9.0 - themes, vim-like leader key shortcuts, other shortcuts etc...
- pton_xd 1y ago
  Wondering the same. I've been using magit for a long time now and never use the git cli anymore. Going back to manually typing in commands doesn't sound appealing. The unified index/workspace non-stash-workflow does sound somewhat nice, though.
jackblemming 1y ago
I must be getting old because I really don’t think git needs a simplified model. But hey, if people find value from this, more power to them. The blog is well written too.
- RGBCube 1y ago
  It's not a "simplified model". The jujutsu model is more capable, but also more generic and thus easier to use and re-use. It's just better.
- doritosfan84 1y ago
  I don’t think simplified model is even the best selling point, but it’s definitely up there. IMO one of the killer features that you absolutely cannot get in git is universal undo. For example, rebases can always be a little tedious and tricky no matter how experienced you are. Not only does jj make that whole process easier and safer to work through, but if you do still manage to get to a state where you just want to go back it’s literally just an undo away. I’d give [1] a read if you’re interested. 1. https://zerowidth.com/2025/what-ive-learned-from-jj/#commits-and-intentionality https://zerowidth.com/2025/what-ive-learned-from-jj/#commits...
- stouset 1y ago
  It’s not just that it’s simpler, it’s that the primitives and interaction model are also strictly more powerful. A ton of extremely useful workflows that are an utter pain in the ass with git are absolutely trivial with jj. One example is a series of dependent PRs. This is excruciating in git if you ever need to make a fix to an earlier PR because you have to manually rebase every subsequent change. It’s trivial in jj: you either fix the revision directly or you insert a new revision inbetween. The subsequent revisions are updated automatically. You don’t even have to think. Another is splitting work into parallel branches. So often when I’m working on one area I end up making unrelated tweaks and improvements as I go. Pulling these out into their own branches is painful in git, so people just make omnibus branches that include a handful of unrelated work alongside the main task. In jj it’s basically zero work to split out the unrelated stuff onto a new branch off main, and it doesn’t require you to task-switch to a new branch. So I end up making lots of one-line PRs that are trivial to review whenever I’m doing deeper work.
doritosfan84 1y ago
I’ve been trying unsuccessfully to convert my team to jujutsu. I feel like what would be great is a page that really shows some common but complicated operations in git and how much easier they are in jujutsu. Something like the elevator pitch here but expanded on without the depth of Steve’s tutorial. Maybe what I need to do is do a demo so people can see and ask questions.
- arp242 1y ago
  I don't especially like git. I stuck with mercurial for a long time. But that was ten years ago. Now git is kind of hard-wired in my brain. By and large, it works well enough. It's not really clear to me that Jujutsu offers a significant enough of a benefit to spend the time re-wiring my brain, never mind dealing with the initial setup (e.g. the unreadable colours, setting up some scripts/aliases for things I like).
  - sunshowers 1y ago
    I think jj just uses the 4 bit (16 color) terminal palette, so if a color is unreadable, you can update your terminal theme accordingly.
    - steveklabnik 1y ago
      This has been the case, but it's worth noting that very recently, support for theming with the 256-color palette has landed too https://github.com/jj-vcs/jj/pull/6763 https://github.com/jj-vcs/jj/pull/6763
      - sunshowers 1y ago
        Cool! Don't imagine it would ever be the default, though.
        steveklabnik 1y ago
        I hope not, for sure.
Lyngbakr 1y ago
I feel pretty dense, because I still struggle to get my head around automatically adding changes to a revision. Sometimes, I'll make a change locally to a file that I'll use during the development process that I have no intention of committing. With regular git, I never stage that file so there's no danger of accidentally pushing my change to the remote repo, but it seems with jj I'll need to somehow unstage that change or something to prevent this. Perhaps it's just habit, but I feel more comfortable explicitly saying what I want to commit rather that defaulting to everything. Or have I totally misunderstood jj?
- do_not_redeem 1y ago
  If you want this workflow, you can treat jj's `@` (nominally equivalent to git's HEAD) as the git index, then at commit time, manually squash changes to `@-` just like you would with `git add --patch`.
  - 000ooo000 1y ago
    FWIW, @ is a shortcut for HEAD in Git.
  - Nzen 1y ago
    When I've asked about using a jj stage, that's the workflow people pointed me to, as described in this tutorial [0]. I've not tried it, nor jujutsu, but I felt it worth pointing at a concrete example to allay or stoke fears of people on the fence. [0] https://steveklabnik.github.io/jujutsu-tutorial/real-world-workflows/the-squash-workflow.html https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...
- 0cf8612b2e1e 1y ago
  No that is correct, and also a habit I am trying to break. The reasonable argument is that we should stop running code with untracked state. Either the changes are important and should be committed or not. Otherwise you are recording code versions that never truly existed during development. Where this gets extra sticky for me is tooling which refuses to distinguish repo wide config vs a local only version. VSCode being a huge offender where there is only a ‘launch.json’ and no ‘launch.local.json’ suitable for per host customization (eg maybe I am already running something on port 8888, so I need to map it to 9000, that does not mean a quirk of my environment should be committed).
Heliodex 1y ago
Accessible without clientside JS enabled: https://web.archive.org/web/20250722002855/https://maddie.wtf/posts/2025-07-21-jujutsu-for-busy-devs https://web.archive.org/web/20250722002855/https://maddie.wt...
_bent 1y ago
I've been using jj for two weeks now and it's kinda exciting, because for the first time I'm comfortable with using version control just via the command line. With Git I always had to use a GUI (preferably Git Graph in VSCode) and launch all operations by right clicking items, but jj was simple and consistent enough that I could just start using it after reading Steve Klabniks tutorial. The thing I'm running into right now is that I should really learn the revset language, so that I don't have to constantly copy paste ids from jj log
- benoitg 1y ago
  I had the same copy paste problem, now I use jjui (https://github.com/idursun/jjui https://github.com/idursun/jjui). The daily operations become even smoother, it looks like I’m flying over the log.
  - nchmy 1y ago
    This is The Way. jjui makes jj's power and simplicity even more powerful, simple and beautiful
- noroot 1y ago
  I'm in a very similar situation: been using git for a long time, but anything more complicated always via some kind of UI (often intellij). Been using jj without significant issues for about a month and been super happy to be comfortable using the cli and slowly ramping up to more complicated operations. The documentation still assumes a lot of inherent knowledge which sometimes makes it a little difficult. I love seeing blog posts like these and hopefully some more in depth resources will appear over time. Steve's guide is good, but there are still gaps for me :). Next I want to learn some more revset language and become a bit more fluent with rebase operations. I love the more simplified cli, conflict resolution and op log!
zamalek 1y ago
I've been using jj for a few weeks, and recently made an auto-commit-message script for it[1]. Just today I started working in an old git repo and thought that I should port the script to git. It turns out that jj made the script trivial because of immutable commits, and mt script would need to automatically do that with git: I use a rebase/amend/clean history workflow at work, so I would need the script to determine when to commit or when to amend. It's obviously possible, but I don't want to expend the effort - I just re-cloned it with jj. It's amazing how quickly I forgot about the commit vs. amend papercut. [1]: https://codeberg.org/jcdickinson/nix/src/branch/main/home/common/scripts/jj-auto.fish https://codeberg.org/jcdickinson/nix/src/branch/main/home/co...
- MForster 1y ago
  You don't even need to re-clone. You can add jj to an existing git repo.
sieve 1y ago
JJ is brilliant. I reluctantly moved to git from mercurial when host-after-host dropped mercurial support. git is a user-hostile POS that I never got used to. A thousand needless complications including nightmare merges, and an inscrutable command interface. JJ eliminates all the git bullshit. Some incredible features: * Merges never fail as conflicts are a first class feature. You can come back and resolve them at any time. * You can reset the state of the repo to any particular point in history as JJ maintains a complete operations history. * You can insert new changes anywhere and deal with the repercussions at leisure. I started with Steve's tutorial but found it a bit wordy. So I used Gemini to produce a simple guide for me with: "You are an expert at DVCS systems like JJ. Act as my guide for the system and answer my questions with simple cookbook-style recipes." I have been using JJ for a month and am never going back to git. It is such a pleasure to work with a DVCS that you don't have to fight at every turn.
Svoka 1y ago
I want to be excited about Jujutsu, but what always bothers me about JJ is that if you search the page you can find 'jj' 47 times and 'git' - 49. Is there a good explanation of Jujutsu without referring to git? May be with some pictures? Am I the only one bad with memorizing SHAs when reading? Also, does it work with other people? Would it work in repo with 5 contributors? 20? 500? EDIT: I am looking for tutorials with explanation on how JJ works, preferably without referring to Git, and even more preferably with some visual explanations, which, there are plenty for Git. It seems I am not very good in reading text trees. It is my issue, not yours, but may be you know something which would help.
- matthewkmayer 1y ago
  Try https://senekor.github.io/jj-for-everyone/introduction.html https://senekor.github.io/jj-for-everyone/introduction.html . A snippet from the intro: "At the time of writing, most Jujutsu tutorials are targeted at experienced Git users, teaching them how to transfer their existing Git skills over to Jujutsu. This blog post is my attempt to fill the void of beginner learning material for Jujutsu."
  - Svoka 1y ago
    Thank you!
  - dcre 1y ago
    That’s very fun. I’ve been wondering what would happen if someone new to programming started with jj directly.
- steveklabnik 1y ago
  > Is there a good explanation of Jujutsu without referring to git? There can and will be, but at this stage in the project's life, git familiarity can be assumed. > Am I the only one bad with memorizing SHAs when reading? Nope! The CLI has nice syntax highlighting to show you the shortest valid prefix, so for example, right now I have something that looks like lzrvnkxl but the initial l is in purple, while the zrvnkxl is in grey. This means I can just use the l when referring to the change. That can be harder to demonstrate in a blog post, which can't know how to highlight this, and so often they have no highlighting. > Also, does it work with other people? Would it work in repo with 5 contributors? 20? 500? Yes. Because it's backed by a git repo, nobody else needs to know you're using jj. Everyone can use the tool they choose.
stouset 1y ago
For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out of inertia. Of course both of these do happen—nothing is perfect—but they are by far the exception. From my own personal anecadata, I have seen a 100% conversion rate from everyone who gave it a serious try. I encourage you to let today be the day that you decide to try it out. It is far less effort to make the switch than you probably think it is: I was productive the same day I switched and within a week I had no remaining situations where I needed to fall back to git commands. You will quickly be more productive and you will find yourself amazed at how you ever got by without it.
- 0x457 1y ago
  Reason I like git is because I use like 2% of its features. I don't fall for propaganda that I need to use bisect and co. 99% of git commands I call are aliased to 3 characters, so it's dense terminology doesn't bother me.
  - Valodim 1y ago
    There were (are?) people who say the same thing about svn
    - 0x457 1y ago
      Sure, but in this case, git being distributed is what sold it for me. I've switched off svn as soon as I've learned of git.
  - globular-toast 1y ago
    I relish the day I get to use bisect. It's like, finally I get to use all this version data I've been collecting. I don't understand why anyone would say you have to use it. It does a very specific thing, namely finding the source of a regression between two commits. If you need it you'll know.
ants_everywhere 1y ago
I'm confused what this is? Is it just a git frontend for people who are confused by git? It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits. Some of the design decisions are also not great. Working copy as commit means you have no quality control. The whole point of a commit is that... you commit it. So now you need a separate repo or filter to remove the worthless changes from the ones that you actually intend to commit. Bad commits polluting git histories is already a big problem. The biggest problems with git IMO are it scales poorly and it encourages commit pollution. Presumably jj isn't trying to tackle those problems, which is totally fine. But I am confused about which problems it is tackling. That's why I'm wondering whether it's just a frontend that the author finds more to their liking.
- do_not_redeem 1y ago
  > Working copy as commit means you have no quality control The working copy doesn't get automatically pushed to GitHub or anything crazy like this seems to be implying. You review/curate your commit when you give it a description.
- Filligree 1y ago
  > It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits. Its Piper backend honestly works better than the Git backend. Which isn't a knock on the Git backend, but the impedance mismatch is worse there. > Some of the design decisions are also not great. Working copy as commit means you have no quality control. The whole point of a commit is that... you commit it. So now you need a separate repo or filter to remove the worthless changes from the ones that you actually intend to commit. Bad commits polluting git histories is already a big problem. Sorry, but saying this implies you haven't tried it. :-) Jujutsu commits aren't equivalent to Git commits. They're implemented with a mixture of Git commits and the Git working tree, yes (if you use the Git backend!), but when you see 'commit', you should read 'named diff'. Jujutsu also has a notion of immutable commits, by default meaning (roughly) commits which have been pushed upstream. You can and should rewrite the un-pushed commits to clean up history prior to pushing changes upstream. jj makes that much MUCH easier than rebases and history edits could ever be with git. Most of my nontrivial jj work involves at least three or four commits at some point, everything from experiments to documentation branches, which with git I would have needed to awkwardly fit into stash or inconvenient throwaway branches.
flockonus 1y ago
I legit ask myself how many folks avoid Github Desktop for some dogmatic reasoning equivalent to "having an UI makes it worse", when it does the core of common flows extremely easily and clear. To be clear where it ties to this post: it makes git far more convenient with nearly 0 learning curve.
- vasco 1y ago
  Can't be leet like that!
- MoltenMan 1y ago
  When I was first learning coding, git, etc. and had no clue how git worked I downloaded GitHub desktop and used that. It's true that I was much younger and less knowledgeable then so it's possible that's influencing me but man when you actually understand git the cli just feels so much smoother, cleaner, and faster. It really doesn't take much dedicated to time to learn the top 5 commands you'll use 95% of the time and if you don't know git currently I think it's probably one of the most leveraged ways you can spend your time.
- nottorp 1y ago
  Judging by the name, Github Desktop works only with github... ?
  - aniforprez 1y ago
    I'm not sure if there's advanced commands that GitHub Desktop does more with but for the most part it's just a porcelain frontend that works great for doing simple operations but can't do things like interactive rebases, reflogs, blames and so on. It's a pretty simple frontend to get started if you're just learning git. There's not much it does that's GitHub specific. If you're logged in, it will easily checkout your upstream repos.
- km144 1y ago
  My thought is, if a GUI like GH Desktop makes it hard to use Git, then your workflow is too complicated. Version control doesn't have to be complicated. But a lot of that is upstream decisions about how you structure your work as a team.
kadhirvelm 1y ago
I’ve had a lot of success using https://graphite.dev/ https://graphite.dev/. Been pretty easy to pick up and slots right into our usual GitHub workflow. I end up using the vscode extension to manage it. Anyone have opinions how jujutsu compares?
- ramon156 1y ago
  Isn't graphite a pr review tool that still uses git?
  - riwsky 1y ago
    It’s both. Their CLI has a lot of overlap with what you’d use jj for (rebasing, amending, etc), but does basically everything worse other than “creating stacked PRs”. Slower; refuses to work from a detached HEAD; gets confused more easily by changes on the remote.
    - kadhirvelm 1y ago
      Sounds like your opinion is jj is easier and faster? Would you say that’s true for new developer onboarding too?
      - riwsky 1y ago
        I’ve never onboarded or successfully convinced a colleague to use jj. But roughly once a month I find myself helping someone escape git hell that would either be easier to solve or avoided entirely with jujutsu. I’m not speaking hypothetically: I will solve the problem locally while waiting for them to slog through whatever merge conflicts or stash/unstash dances. But the graphite CLI’s stacked PR review is a killer app. Our team uses it, but treats the rebase-centric workflow as the price of stacked review, instead of a mental model to leverage. I end up using jj but with a helper script to set up graphite’s branch tracking whenever I want to submit a stacked PR. I also was always a git CLI person. I’d do diffs and resolve conflicts in a proper editor, I wasn’t crazy—but I know that changing just my mental model is less work than it’d be to change the UI habits as well.
fouc 1y ago
Lately I've been hearing more people are getting into jj because of how much easier it is to keep track of the code generated with tools like cursor or claude code.
- stouset 1y ago
  Yes! I have found it incredibly helpful when using an agent. It's a great case for the "staging-area" style workflow. I `jj new` an empty revision where the LLM can go hog-wild. When I'm generally happy with the LLM's work, I make a new revision. Then I ask it to make some improvements. Sometimes I have to discard those. No problem, I just `jj abandon` the whole thing. Sometimes I like a few pieces; I `jj squash -i` those into the parent revision with the bulk of the work and abandon the rest. And then I repeat until I'm happy with the overall output. It's also super useful when I need to go fix something in an earlier (but still unmerged) revision. `jj new {id}` creates a new revision whose parent is the older change, even if it already has children. Again, I let the agent loose. When I'm happy, I `jj squash -i` what I want and the fixes are not only incorporated back into the parent but then propagated automatically down through the rest of its children through automatic rebasing.
  - 1718627440 1y ago
    I wonder when LLMs will start messing with VCS. That will be fun :-/
    - steveklabnik 1y ago
      Most coding llms already know git, and can handle jj pretty well too.
      - 1718627440 1y ago
        I expect them to, I ment, that as part of modifying the code the issue commands that affect the VCS. This would be annoying, because you then can't rely on the VCS to tell you what the LLM did.
atkailash 1y ago
I tried it out on one of my personal repos and I need to give it more time. I do like the way it tracks work, it feels like it would help me to make more commits as I work, cause I’m really bad about that
miguel_martin 1y ago
How does this compare to sapling? https://github.com/facebook/sapling https://github.com/facebook/sapling
- miguel_martin 1y ago
  Found a comparison: https://github.com/jj-vcs/jj/blob/main/docs/sapling-comparison.md https://github.com/jj-vcs/jj/blob/main/docs/sapling-comparis...
simonebrunozzi 1y ago
Isn't it supposed to be called Ju-Jitsu, instead of Jujutsu?
- GolDDranks 1y ago
  Supposed by who? Maybe it's supposed to be 柔術.
- ben0x539 1y ago
  Wikipedia has some background on the spelling: https://en.wikipedia.org/wiki/Jujutsu#Etymology https://en.wikipedia.org/wiki/Jujutsu#Etymology > Jujutsu is derived using the Hepburn romanization system. Before the first half of the 20th century, however, jiu-jitsu and ju-jitsu were preferred,
- nirui 1y ago
  You guys are nitpicking on the name while I clicked the link seriously thinking it's cool and could help to shrink my bellyfat.
fn-mote 1y ago
Any tips for a magit fan who wants a positive second experience with jj? I’m used to sorting through the changes I have made and making separate commits for each unrelated one (eg bug fix for several files, some WIP work, other parts actually done and ready to be “shipped”/reviewed)? Do I need a better workflow? Should I just be using the command line?
- fxmc 1y ago
  I came from magit and completely switched to jj for the much easier handling of sets of changes that you describe. jjui (https://github.com/idursun/jjui https://github.com/idursun/jjui) made this a lot faster and more enjoyable.
  - nchmy 1y ago
    This x1000. Jjui is beautiful
sam_goody 1y ago
JJ needs a GUI. I tried twice to switch for a project, both times came back to git. But then, I am still not fully grokking the "why bother", and suspect that if I had a UI it would be both less friction, and more understanding.
- nchmy 1y ago
  There's lots of TUIs and even some GUIs (including a vs code extension), but the best by far is jjui https://github.com/idursun/jjui https://github.com/idursun/jjui
- baq 1y ago
  small projects and/or projects with few collaborators don't benefit as much from jj as the big, fast moving ones. you can easily stick to git and be happy as the differences are not really apparent.
mihaic 1y ago
For a decade now I've been lamenting that git won the source control war. My complaints fall in two main categories: 1. The mental model is too complex: rebase or merge, detaching head, etc. A good UI can hide away some of this uglyness. It sounds like jj helps here. 2. Any source control in a terminal is just horrible, since you have no view of the state you're working with. I honestly never fully understood why developers have such religious elitism for the command line. Where would you draw the line on something having a complex enough state to need a UI? The change to git that I'm hoping for is a GUI on top of a simpler wrapper like Jujutsu.
- nchmy 1y ago
  jjui is what you're looking for. jj is amazing and jjui makes it incredibly better. The maintainer is extremely receptive and responsive to feedback, and constantly moving it forward. There's other TUIs and GUIs, but jjui is by far the best. https://github.com/idursun/jjui https://github.com/idursun/jjui
WhyNotHugo 1y ago
The main things that drives me crazy about jj is that all changes are always staged implicitly. This is what SVN did back in the day, and git was a huge improvement by staging changes explicitly. I almost always have more changes in my repository that those which I want to include in the next commit. With git, I just add the changes I want. With jj (and svn), there’s not obvious way around it—you have to manually copy-paste changes outside of the repository before committing.
- padenot 1y ago
  `jj commit -i` (or a lot of commands `-i`) and maybe `snapshot.auto-track="none()"` in the config, to a certain extent is what I use. I used to do the same with mercurial. In practice, I also use `absorb` a lot, that leaves unrelated files and chunks alone.
- kirici 1y ago
  You could disable autom snapshots or use `jj split -i`, which I use almost exclusively
  - nchmy 1y ago
    I just discovered interactive split last week. Absolutely beautiful.
- tapirl 1y ago
  Isn't "jj new" what you need?
- baq 1y ago
  jj is actaully great at this since it natively tracks branches which aren't heads correctly, so all rebases and merges work without stashing.
- vander_elst 1y ago
  I think the workflow in JJ is a bit different in this case, you can try to have a base commit `jj new -m 'base'`, then create an anonymous commit on top `jj new`, then make some changes in the anonymous commit and when you are ready to send out a PR/MR you squash `jj squash` or split `jj split` and squash what you need in the base commit.
koakuma-chan 1y ago
jj is unusable at least because there is tooling built around git repositories specifically
- nchmy 1y ago
  jj itself is tooling built around git repos... It just works seamlessly with any git repo. And there's toppling built around jj, such as jjui https://github.com/idursun/jjui https://github.com/idursun/jjui
  - koakuma-chan 1y ago
    Oh --colocate is what I needed.
    - nchmy 1y ago
      Yup! And you can just do jj git init --colocate in an already-cloned repo and it'll start working immediately, seamlessly. No need to re-clone it via jj git clone --colocate
eulgro 1y ago
I've never tried jj, but recently I discovered lazygit which in my opinion comes pretty close to perfection. Rebasing can be done instantly (reorder commits, fixups, squash), I can extract and reverse custom patches from previous commits, I can partially stage files, undo. One think I like is that it explains what it does in terms of git commands. So it helps a little to have a good git mental model, and as such I guess it doesn't solve the same thing as jj.
- xcubic 1y ago
  This is the reason I have not gone the jj way.
- lysp 1y ago
  There is lazyjj which follows a similar theme. Haven't used enough of either to give a good comparison other than lazyjj being earlier in its journey.
deleted 1y ago
[deleted]
simonmic 1y ago
That's a very clear up-to-date intro, great work.
emresahin 1y ago
I tried jj a few days but I noticed my lazygit based workflow and scripts already make me productive enough not to deal with another mental model. jj looks cool in general, I'd start with it if I were just going into this _version control_ thing but for most of us older folks, that doesn't provide enough motivation to change.
- stavros 1y ago
  Eh, I can see how, if you use GitButler, the porcelain is fairly irrelevant to you, but a few days ago I decided to try Jujutsu, asked Claude how I could do a few things that came up (commit, move branches, push/pull to Github). It took me ten minutes to become proficiend in Jujutsu, and now it's my VCS of choice. I still use Lazygit for the improved diffing, but, as long as you don't mind being in detached HEAD all the time, there's really no issue with doing that. JJ interoperates fine with git, but why would I use the arcane git commands when JJ will do the same thing much more straightforwardly? Also, the ability to jump from branch to branch with all my uncommitted files traveling with me is a godsend. Now I can breeze between feature development, bug fixing, copy changing, etc just by editing the commit I want. If I want multiple AI agents working on that stuff, I just make a worktree and get on with it. Not to mention that I am really liking the fact that I can describe changes (basically add commit messages) before I'm done with them, so I can see them in the tree. JJ is just all around great.
exclipy 1y ago
I tried it for a bit and went back to git-branchless (https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless). git-branchless is just a better set of tools for working on a git repo so local tools like the JetBrains git integration will work just fine. It operates on a similar philosophy to Jujutsu (make it easy to manipulate the commit tree) and the authors did exchange ideas with each other.
- KingMob 1y ago
  It seems like a lot more than they "did exchange ideas". Arxanas, the lead dev of git-branchless, is also one of the major devs and maintainers of jj. He's active on the jj discord, and just last month put out a call on github for a jj side conference during Git Merge 2025.
tomasyany 1y ago
Don't want to sound old school, but git works perfectly fine. The learning curve might be a bit difficult, but afterwards everything makes sense. And let's be honest, you just need a few actions (pull, add, reset, branch, commit) to use it in 95% of the cases.
- tapirl 1y ago
  just when you face some unusual situations ...
- killerstorm 1y ago
  If you work in a team you need to understand rebasing and squashing, unless you can convince team to never use these features. A lot of people are religious about rebasing, "clean" commit history. But it's pretty much incompatible with several devs working on a single branch. I.e. when you work on something complex, perhaps under time pressure, git habits bite you in the ass. It's not fine.
  - km144 1y ago
    A lot of the time, multiple devs working on a single branch can be avoided via different decisions made upstream about work that needs done. If my job included more git wrangling as one of my daily tasks I would probably hate my job.
  - Cthulhu_ 1y ago
    As soon as you have the situation of multiple people working on the same branch, forbid force pushes at all times. But it's better to avoid that in the first place, all work should be on its own branch at all times. For larger features we often have a feature branch with merge requests for various task branches. Limits the review sizes as well. Of course, you can also then consider to use feature toggles, so there's no feature branch but just your main branch.
  - alexjplant 1y ago
    > A lot of people are religious about rebasing Years and years ago I worked on a team where linear commit history was required so every time a merge happened you had to manually rebase and push to Bitbucket. I put a PR in halfway through the sprint, rebased it a dozen times as everybody else's work got merged, and had nothing to show during review because nobody bothered to check mine and the only coworker I had in the same physical office was out on vacation. When I interview for new roles I always make a habit of asking how work gets done to avoid shops that engage in these types of shenanigans.
kavenkanum 1y ago
If only it was supported by Gui tools... I don't bother use Git from my terminal, but use GiFork instead. As I understand there is nothing that may be interesting for me in my scenario...
- Aerbil313 1y ago
  I actually find I don't need to use any GUI tools with jj because I can actually understand what's going on under the hood since the mental model is much simpler. It helps that jj has excellent visualizations straight in the terminal.
d4rkp4ttern 1y ago
Curious are there nice terminal tools for JJ similar to magit or GitUI?
- drew_h 1y ago
  https://github.com/idursun/jjui https://github.com/idursun/jjui is absolutely fantastic. One of the best TUI's ever created IMO
prokopton 1y ago
I don’t see anything about side control in this post. 3/10.
o140445 1y ago
[dead]
lillecarl 1y ago
My NixOS repo checkout(s) are always cursed with unstaged changes, will jj help me cure this? Sometimes I feel like "this shit is too bad to commit but it does the plumbing for the thing I'm working on right now" and it ends up untracked for weeks... This is just my personal ADHD pool of code but it gets really gnarly before I take care to dissect my unstaged changes into the repo.
- incognito124 1y ago
  Almost certainly. I have a private monorepo where I just try things out in new empty changes and I just leave them hanging
rootnod3 1y ago
Hands down one of the best features in jj is undo. In Git, undoing things is always a bit of an open heart surgery, with different commands depending on what you fucked up. In jj? Just a simple jj undo, done. That alone is a killer feature. Then having the whole thing being kinda agnostic by design to the backend system, that is also a sweet spot. I can comfortably use jj locally without any of my teammates knowing that I use jj instead of git.
vander_elst 1y ago
I've been using JJ as my daily driver for ~6 months. It is so nice to be able to immediately rebase everything on top of everything, undo last command, restore a previous state, ignore and postpone conflict resolution. It is such a boost in productivity!!
reddit_clone 1y ago
Hmm. Here I thought it was about a special martial art variant for chair bound developers !
reddit_clone 1y ago
Went through the whole article. Tried out some commands. I haven't 'got' it yet. I am sure I will after some regular use. But being a long time Magit user, its hard to move to anything else.
ephimetheus 1y ago
So far whenever jujutsu came up I didn’t find its features that convincing relative to git. I have to say however that the mega merge workflow seems intriguing and might in fact be a solution to having to serialize my work like I do in git for now. I think I’ll look into that.
palata 1y ago
A killer feature for Jujutsu would be to make the email workflow cool again: https://github.com/jj-vcs/jj/issues/4438 https://github.com/jj-vcs/jj/issues/4438
brainzap 1y ago
I still dont get it, can nobody explain it properly

383 points by Bogdanp 1y ago

Is there a magit equivalent? I heavily use magit's interactive features and extensions to the git UI (like spinoff, absorb, or the auto-backup thing)

stouset 1y ago
I am not a magit user but from doing a little bit of reading, all of these commands are essentially first-class citizens in jj. Spinoff seems to be `jj split` (or in most cases literally nothing because the default is to edit a new, empty revision off the trunk), absorb is probably `jj rebase` or `jj squash`, and the auto-backup is either the evolog (which tracks file changes that haven't been explicitly commmited) or the op log (which lets you reset the entire repo to what it looked like before or after any operation). There is also lazyjj as an interactive UI.
- Filligree 1y ago
  magit-merge-absorb is one of rebase (if that's what you want), or new (which gets you a merge when you specify multiple parents). The 'delete the branch' part of it doesn't really apply, because jj doesn't have branches; though you might need to delete a tag. Note for other readers: jj also has a literal `jj absorb` command. That one does what you'd expect from mercurial, i.e. moves diffs from the current commit into the most recent ancestral commit where that file was changed.
  - stouset 1y ago
    Note also that jj does have branches, they are just anonymous. You don't checkout a branch or edit a branch, you edit a revision or make a new one. One revision with multiple children is a branching point, one revision with multiple parents is a merge. You name them with bookmarks which are sort of like branch names except they don't follow along automatically as you make new revisions. You can point an existing bookmark at a later revision when you're ready to push new changes.
do_not_redeem 1y ago
jjui is the best VCS TUI I've ever used. It's even smoother than magit, but I think most of that is because of jj itself. Spinoff and absorb are both native jj features (jj rebase and jj absorb, respectively) https://github.com/idursun/jjui https://github.com/idursun/jjui
- tcoff91 1y ago
  I’ve got to check this out. I’ve really been loving these two neovim JJ plugins For splitting commits: https://github.com/julienvincent/hunk.nvim https://github.com/julienvincent/hunk.nvim For resolving conflicts: https://github.com/rafikdraoui/jj-diffconflicts https://github.com/rafikdraoui/jj-diffconflicts
- nchmy 1y ago
  Completely agreed. I've been evangelizing jjui even more than I do jj! And, you're right, it's powers largely come from the underlying jj - it mostly just runs jj commands behind the scenes, parses the output, and displays it. But it's all so beautiful, seamless etc.. I can't wait to really dig into the big additions released yesterday in v0.9.0 - themes, vim-like leader key shortcuts, other shortcuts etc...
pton_xd 1y ago
Wondering the same. I've been using magit for a long time now and never use the git cli anymore. Going back to manually typing in commands doesn't sound appealing. The unified index/workspace non-stash-workflow does sound somewhat nice, though.

jackblemming 1y ago

I must be getting old because I really don’t think git needs a simplified model. But hey, if people find value from this, more power to them. The blog is well written too.

RGBCube 1y ago
It's not a "simplified model". The jujutsu model is more capable, but also more generic and thus easier to use and re-use. It's just better.
doritosfan84 1y ago
I don’t think simplified model is even the best selling point, but it’s definitely up there. IMO one of the killer features that you absolutely cannot get in git is universal undo. For example, rebases can always be a little tedious and tricky no matter how experienced you are. Not only does jj make that whole process easier and safer to work through, but if you do still manage to get to a state where you just want to go back it’s literally just an undo away. I’d give [1] a read if you’re interested. 1. https://zerowidth.com/2025/what-ive-learned-from-jj/#commits-and-intentionality https://zerowidth.com/2025/what-ive-learned-from-jj/#commits...
stouset 1y ago
It’s not just that it’s simpler, it’s that the primitives and interaction model are also strictly more powerful. A ton of extremely useful workflows that are an utter pain in the ass with git are absolutely trivial with jj. One example is a series of dependent PRs. This is excruciating in git if you ever need to make a fix to an earlier PR because you have to manually rebase every subsequent change. It’s trivial in jj: you either fix the revision directly or you insert a new revision inbetween. The subsequent revisions are updated automatically. You don’t even have to think. Another is splitting work into parallel branches. So often when I’m working on one area I end up making unrelated tweaks and improvements as I go. Pulling these out into their own branches is painful in git, so people just make omnibus branches that include a handful of unrelated work alongside the main task. In jj it’s basically zero work to split out the unrelated stuff onto a new branch off main, and it doesn’t require you to task-switch to a new branch. So I end up making lots of one-line PRs that are trivial to review whenever I’m doing deeper work.

doritosfan84 1y ago

I’ve been trying unsuccessfully to convert my team to jujutsu. I feel like what would be great is a page that really shows some common but complicated operations in git and how much easier they are in jujutsu. Something like the elevator pitch here but expanded on without the depth of Steve’s tutorial. Maybe what I need to do is do a demo so people can see and ask questions.

arp242 1y ago
I don't especially like git. I stuck with mercurial for a long time. But that was ten years ago. Now git is kind of hard-wired in my brain. By and large, it works well enough. It's not really clear to me that Jujutsu offers a significant enough of a benefit to spend the time re-wiring my brain, never mind dealing with the initial setup (e.g. the unreadable colours, setting up some scripts/aliases for things I like).
- sunshowers 1y ago
  I think jj just uses the 4 bit (16 color) terminal palette, so if a color is unreadable, you can update your terminal theme accordingly.
  - steveklabnik 1y ago
    This has been the case, but it's worth noting that very recently, support for theming with the 256-color palette has landed too https://github.com/jj-vcs/jj/pull/6763 https://github.com/jj-vcs/jj/pull/6763
    - sunshowers 1y ago
      Cool! Don't imagine it would ever be the default, though.
      - steveklabnik 1y ago
        I hope not, for sure.

Lyngbakr 1y ago

I feel pretty dense, because I still struggle to get my head around automatically adding changes to a revision. Sometimes, I'll make a change locally to a file that I'll use during the development process that I have no intention of committing. With regular git, I never stage that file so there's no danger of accidentally pushing my change to the remote repo, but it seems with jj I'll need to somehow unstage that change or something to prevent this. Perhaps it's just habit, but I feel more comfortable explicitly saying what I want to commit rather that defaulting to everything. Or have I totally misunderstood jj?

do_not_redeem 1y ago
If you want this workflow, you can treat jj's `@` (nominally equivalent to git's HEAD) as the git index, then at commit time, manually squash changes to `@-` just like you would with `git add --patch`.
- 000ooo000 1y ago
  FWIW, @ is a shortcut for HEAD in Git.
- Nzen 1y ago
  When I've asked about using a jj stage, that's the workflow people pointed me to, as described in this tutorial [0]. I've not tried it, nor jujutsu, but I felt it worth pointing at a concrete example to allay or stoke fears of people on the fence. [0] https://steveklabnik.github.io/jujutsu-tutorial/real-world-workflows/the-squash-workflow.html https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...
0cf8612b2e1e 1y ago
No that is correct, and also a habit I am trying to break. The reasonable argument is that we should stop running code with untracked state. Either the changes are important and should be committed or not. Otherwise you are recording code versions that never truly existed during development. Where this gets extra sticky for me is tooling which refuses to distinguish repo wide config vs a local only version. VSCode being a huge offender where there is only a ‘launch.json’ and no ‘launch.local.json’ suitable for per host customization (eg maybe I am already running something on port 8888, so I need to map it to 9000, that does not mean a quirk of my environment should be committed).

Heliodex 1y ago

Accessible without clientside JS enabled: https://web.archive.org/web/20250722002855/https://maddie.wtf/posts/2025-07-21-jujutsu-for-busy-devs https://web.archive.org/web/20250722002855/https://maddie.wt...

_bent 1y ago

I've been using jj for two weeks now and it's kinda exciting, because for the first time I'm comfortable with using version control just via the command line. With Git I always had to use a GUI (preferably Git Graph in VSCode) and launch all operations by right clicking items, but jj was simple and consistent enough that I could just start using it after reading Steve Klabniks tutorial. The thing I'm running into right now is that I should really learn the revset language, so that I don't have to constantly copy paste ids from jj log

benoitg 1y ago
I had the same copy paste problem, now I use jjui (https://github.com/idursun/jjui https://github.com/idursun/jjui). The daily operations become even smoother, it looks like I’m flying over the log.
- nchmy 1y ago
  This is The Way. jjui makes jj's power and simplicity even more powerful, simple and beautiful
noroot 1y ago
I'm in a very similar situation: been using git for a long time, but anything more complicated always via some kind of UI (often intellij). Been using jj without significant issues for about a month and been super happy to be comfortable using the cli and slowly ramping up to more complicated operations. The documentation still assumes a lot of inherent knowledge which sometimes makes it a little difficult. I love seeing blog posts like these and hopefully some more in depth resources will appear over time. Steve's guide is good, but there are still gaps for me :). Next I want to learn some more revset language and become a bit more fluent with rebase operations. I love the more simplified cli, conflict resolution and op log!

zamalek 1y ago

I've been using jj for a few weeks, and recently made an auto-commit-message script for it[1]. Just today I started working in an old git repo and thought that I should port the script to git. It turns out that jj made the script trivial because of immutable commits, and mt script would need to automatically do that with git: I use a rebase/amend/clean history workflow at work, so I would need the script to determine when to commit or when to amend. It's obviously possible, but I don't want to expend the effort - I just re-cloned it with jj. It's amazing how quickly I forgot about the commit vs. amend papercut. [1]: https://codeberg.org/jcdickinson/nix/src/branch/main/home/common/scripts/jj-auto.fish https://codeberg.org/jcdickinson/nix/src/branch/main/home/co...

MForster 1y ago
You don't even need to re-clone. You can add jj to an existing git repo.

sieve 1y ago

JJ is brilliant. I reluctantly moved to git from mercurial when host-after-host dropped mercurial support. git is a user-hostile POS that I never got used to. A thousand needless complications including nightmare merges, and an inscrutable command interface. JJ eliminates all the git bullshit. Some incredible features: * Merges never fail as conflicts are a first class feature. You can come back and resolve them at any time. * You can reset the state of the repo to any particular point in history as JJ maintains a complete operations history. * You can insert new changes anywhere and deal with the repercussions at leisure. I started with Steve's tutorial but found it a bit wordy. So I used Gemini to produce a simple guide for me with: "You are an expert at DVCS systems like JJ. Act as my guide for the system and answer my questions with simple cookbook-style recipes." I have been using JJ for a month and am never going back to git. It is such a pleasure to work with a DVCS that you don't have to fight at every turn.

Svoka 1y ago

I want to be excited about Jujutsu, but what always bothers me about JJ is that if you search the page you can find 'jj' 47 times and 'git' - 49. Is there a good explanation of Jujutsu without referring to git? May be with some pictures? Am I the only one bad with memorizing SHAs when reading? Also, does it work with other people? Would it work in repo with 5 contributors? 20? 500? EDIT: I am looking for tutorials with explanation on how JJ works, preferably without referring to Git, and even more preferably with some visual explanations, which, there are plenty for Git. It seems I am not very good in reading text trees. It is my issue, not yours, but may be you know something which would help.

matthewkmayer 1y ago
Try https://senekor.github.io/jj-for-everyone/introduction.html https://senekor.github.io/jj-for-everyone/introduction.html . A snippet from the intro: "At the time of writing, most Jujutsu tutorials are targeted at experienced Git users, teaching them how to transfer their existing Git skills over to Jujutsu. This blog post is my attempt to fill the void of beginner learning material for Jujutsu."
- Svoka 1y ago
  Thank you!
- dcre 1y ago
  That’s very fun. I’ve been wondering what would happen if someone new to programming started with jj directly.
steveklabnik 1y ago
> Is there a good explanation of Jujutsu without referring to git? There can and will be, but at this stage in the project's life, git familiarity can be assumed. > Am I the only one bad with memorizing SHAs when reading? Nope! The CLI has nice syntax highlighting to show you the shortest valid prefix, so for example, right now I have something that looks like lzrvnkxl but the initial l is in purple, while the zrvnkxl is in grey. This means I can just use the l when referring to the change. That can be harder to demonstrate in a blog post, which can't know how to highlight this, and so often they have no highlighting. > Also, does it work with other people? Would it work in repo with 5 contributors? 20? 500? Yes. Because it's backed by a git repo, nobody else needs to know you're using jj. Everyone can use the tool they choose.

stouset 1y ago

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out of inertia. Of course both of these do happen—nothing is perfect—but they are by far the exception. From my own personal anecadata, I have seen a 100% conversion rate from everyone who gave it a serious try. I encourage you to let today be the day that you decide to try it out. It is far less effort to make the switch than you probably think it is: I was productive the same day I switched and within a week I had no remaining situations where I needed to fall back to git commands. You will quickly be more productive and you will find yourself amazed at how you ever got by without it.

0x457 1y ago
Reason I like git is because I use like 2% of its features. I don't fall for propaganda that I need to use bisect and co. 99% of git commands I call are aliased to 3 characters, so it's dense terminology doesn't bother me.
- Valodim 1y ago
  There were (are?) people who say the same thing about svn
  - 0x457 1y ago
    Sure, but in this case, git being distributed is what sold it for me. I've switched off svn as soon as I've learned of git.
- globular-toast 1y ago
  I relish the day I get to use bisect. It's like, finally I get to use all this version data I've been collecting. I don't understand why anyone would say you have to use it. It does a very specific thing, namely finding the source of a regression between two commits. If you need it you'll know.

ants_everywhere 1y ago

I'm confused what this is? Is it just a git frontend for people who are confused by git? It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits. Some of the design decisions are also not great. Working copy as commit means you have no quality control. The whole point of a commit is that... you commit it. So now you need a separate repo or filter to remove the worthless changes from the ones that you actually intend to commit. Bad commits polluting git histories is already a big problem. The biggest problems with git IMO are it scales poorly and it encourages commit pollution. Presumably jj isn't trying to tackle those problems, which is totally fine. But I am confused about which problems it is tackling. That's why I'm wondering whether it's just a frontend that the author finds more to their liking.

do_not_redeem 1y ago
> Working copy as commit means you have no quality control The working copy doesn't get automatically pushed to GitHub or anything crazy like this seems to be implying. You review/curate your commit when you give it a description.
Filligree 1y ago
> It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits. Its Piper backend honestly works better than the Git backend. Which isn't a knock on the Git backend, but the impedance mismatch is worse there. > Some of the design decisions are also not great. Working copy as commit means you have no quality control. The whole point of a commit is that... you commit it. So now you need a separate repo or filter to remove the worthless changes from the ones that you actually intend to commit. Bad commits polluting git histories is already a big problem. Sorry, but saying this implies you haven't tried it. :-) Jujutsu commits aren't equivalent to Git commits. They're implemented with a mixture of Git commits and the Git working tree, yes (if you use the Git backend!), but when you see 'commit', you should read 'named diff'. Jujutsu also has a notion of immutable commits, by default meaning (roughly) commits which have been pushed upstream. You can and should rewrite the un-pushed commits to clean up history prior to pushing changes upstream. jj makes that much MUCH easier than rebases and history edits could ever be with git. Most of my nontrivial jj work involves at least three or four commits at some point, everything from experiments to documentation branches, which with git I would have needed to awkwardly fit into stash or inconvenient throwaway branches.

flockonus 1y ago

I legit ask myself how many folks avoid Github Desktop for some dogmatic reasoning equivalent to "having an UI makes it worse", when it does the core of common flows extremely easily and clear. To be clear where it ties to this post: it makes git far more convenient with nearly 0 learning curve.

vasco 1y ago
Can't be leet like that!
MoltenMan 1y ago
When I was first learning coding, git, etc. and had no clue how git worked I downloaded GitHub desktop and used that. It's true that I was much younger and less knowledgeable then so it's possible that's influencing me but man when you actually understand git the cli just feels so much smoother, cleaner, and faster. It really doesn't take much dedicated to time to learn the top 5 commands you'll use 95% of the time and if you don't know git currently I think it's probably one of the most leveraged ways you can spend your time.
nottorp 1y ago
Judging by the name, Github Desktop works only with github... ?
- aniforprez 1y ago
  I'm not sure if there's advanced commands that GitHub Desktop does more with but for the most part it's just a porcelain frontend that works great for doing simple operations but can't do things like interactive rebases, reflogs, blames and so on. It's a pretty simple frontend to get started if you're just learning git. There's not much it does that's GitHub specific. If you're logged in, it will easily checkout your upstream repos.
km144 1y ago
My thought is, if a GUI like GH Desktop makes it hard to use Git, then your workflow is too complicated. Version control doesn't have to be complicated. But a lot of that is upstream decisions about how you structure your work as a team.

kadhirvelm 1y ago

I’ve had a lot of success using https://graphite.dev/ https://graphite.dev/. Been pretty easy to pick up and slots right into our usual GitHub workflow. I end up using the vscode extension to manage it. Anyone have opinions how jujutsu compares?

ramon156 1y ago
Isn't graphite a pr review tool that still uses git?
- riwsky 1y ago
  It’s both. Their CLI has a lot of overlap with what you’d use jj for (rebasing, amending, etc), but does basically everything worse other than “creating stacked PRs”. Slower; refuses to work from a detached HEAD; gets confused more easily by changes on the remote.
  - kadhirvelm 1y ago
    Sounds like your opinion is jj is easier and faster? Would you say that’s true for new developer onboarding too?
    - riwsky 1y ago
      I’ve never onboarded or successfully convinced a colleague to use jj. But roughly once a month I find myself helping someone escape git hell that would either be easier to solve or avoided entirely with jujutsu. I’m not speaking hypothetically: I will solve the problem locally while waiting for them to slog through whatever merge conflicts or stash/unstash dances. But the graphite CLI’s stacked PR review is a killer app. Our team uses it, but treats the rebase-centric workflow as the price of stacked review, instead of a mental model to leverage. I end up using jj but with a helper script to set up graphite’s branch tracking whenever I want to submit a stacked PR. I also was always a git CLI person. I’d do diffs and resolve conflicts in a proper editor, I wasn’t crazy—but I know that changing just my mental model is less work than it’d be to change the UI habits as well.

fouc 1y ago

Lately I've been hearing more people are getting into jj because of how much easier it is to keep track of the code generated with tools like cursor or claude code.

stouset 1y ago
Yes! I have found it incredibly helpful when using an agent. It's a great case for the "staging-area" style workflow. I `jj new` an empty revision where the LLM can go hog-wild. When I'm generally happy with the LLM's work, I make a new revision. Then I ask it to make some improvements. Sometimes I have to discard those. No problem, I just `jj abandon` the whole thing. Sometimes I like a few pieces; I `jj squash -i` those into the parent revision with the bulk of the work and abandon the rest. And then I repeat until I'm happy with the overall output. It's also super useful when I need to go fix something in an earlier (but still unmerged) revision. `jj new {id}` creates a new revision whose parent is the older change, even if it already has children. Again, I let the agent loose. When I'm happy, I `jj squash -i` what I want and the fixes are not only incorporated back into the parent but then propagated automatically down through the rest of its children through automatic rebasing.
- 1718627440 1y ago
  I wonder when LLMs will start messing with VCS. That will be fun :-/
  - steveklabnik 1y ago
    Most coding llms already know git, and can handle jj pretty well too.
    - 1718627440 1y ago
      I expect them to, I ment, that as part of modifying the code the issue commands that affect the VCS. This would be annoying, because you then can't rely on the VCS to tell you what the LLM did.

atkailash 1y ago

I tried it out on one of my personal repos and I need to give it more time. I do like the way it tracks work, it feels like it would help me to make more commits as I work, cause I’m really bad about that

miguel_martin 1y ago

How does this compare to sapling? https://github.com/facebook/sapling https://github.com/facebook/sapling

miguel_martin 1y ago
Found a comparison: https://github.com/jj-vcs/jj/blob/main/docs/sapling-comparison.md https://github.com/jj-vcs/jj/blob/main/docs/sapling-comparis...

simonebrunozzi 1y ago

Isn't it supposed to be called Ju-Jitsu, instead of Jujutsu?

GolDDranks 1y ago
Supposed by who? Maybe it's supposed to be 柔術.
ben0x539 1y ago
Wikipedia has some background on the spelling: https://en.wikipedia.org/wiki/Jujutsu#Etymology https://en.wikipedia.org/wiki/Jujutsu#Etymology > Jujutsu is derived using the Hepburn romanization system. Before the first half of the 20th century, however, jiu-jitsu and ju-jitsu were preferred,
nirui 1y ago
You guys are nitpicking on the name while I clicked the link seriously thinking it's cool and could help to shrink my bellyfat.

fn-mote 1y ago

Any tips for a magit fan who wants a positive second experience with jj? I’m used to sorting through the changes I have made and making separate commits for each unrelated one (eg bug fix for several files, some WIP work, other parts actually done and ready to be “shipped”/reviewed)? Do I need a better workflow? Should I just be using the command line?

fxmc 1y ago
I came from magit and completely switched to jj for the much easier handling of sets of changes that you describe. jjui (https://github.com/idursun/jjui https://github.com/idursun/jjui) made this a lot faster and more enjoyable.
- nchmy 1y ago
  This x1000. Jjui is beautiful

sam_goody 1y ago

JJ needs a GUI. I tried twice to switch for a project, both times came back to git. But then, I am still not fully grokking the "why bother", and suspect that if I had a UI it would be both less friction, and more understanding.

nchmy 1y ago
There's lots of TUIs and even some GUIs (including a vs code extension), but the best by far is jjui https://github.com/idursun/jjui https://github.com/idursun/jjui
baq 1y ago
small projects and/or projects with few collaborators don't benefit as much from jj as the big, fast moving ones. you can easily stick to git and be happy as the differences are not really apparent.

mihaic 1y ago

For a decade now I've been lamenting that git won the source control war. My complaints fall in two main categories: 1. The mental model is too complex: rebase or merge, detaching head, etc. A good UI can hide away some of this uglyness. It sounds like jj helps here. 2. Any source control in a terminal is just horrible, since you have no view of the state you're working with. I honestly never fully understood why developers have such religious elitism for the command line. Where would you draw the line on something having a complex enough state to need a UI? The change to git that I'm hoping for is a GUI on top of a simpler wrapper like Jujutsu.

nchmy 1y ago
jjui is what you're looking for. jj is amazing and jjui makes it incredibly better. The maintainer is extremely receptive and responsive to feedback, and constantly moving it forward. There's other TUIs and GUIs, but jjui is by far the best. https://github.com/idursun/jjui https://github.com/idursun/jjui

WhyNotHugo 1y ago

The main things that drives me crazy about jj is that all changes are always staged implicitly. This is what SVN did back in the day, and git was a huge improvement by staging changes explicitly. I almost always have more changes in my repository that those which I want to include in the next commit. With git, I just add the changes I want. With jj (and svn), there’s not obvious way around it—you have to manually copy-paste changes outside of the repository before committing.

padenot 1y ago
`jj commit -i` (or a lot of commands `-i`) and maybe `snapshot.auto-track="none()"` in the config, to a certain extent is what I use. I used to do the same with mercurial. In practice, I also use `absorb` a lot, that leaves unrelated files and chunks alone.
kirici 1y ago
You could disable autom snapshots or use `jj split -i`, which I use almost exclusively
- nchmy 1y ago
  I just discovered interactive split last week. Absolutely beautiful.
tapirl 1y ago
Isn't "jj new" what you need?
baq 1y ago
jj is actaully great at this since it natively tracks branches which aren't heads correctly, so all rebases and merges work without stashing.
vander_elst 1y ago
I think the workflow in JJ is a bit different in this case, you can try to have a base commit `jj new -m 'base'`, then create an anonymous commit on top `jj new`, then make some changes in the anonymous commit and when you are ready to send out a PR/MR you squash `jj squash` or split `jj split` and squash what you need in the base commit.

koakuma-chan 1y ago

jj is unusable at least because there is tooling built around git repositories specifically

nchmy 1y ago
jj itself is tooling built around git repos... It just works seamlessly with any git repo. And there's toppling built around jj, such as jjui https://github.com/idursun/jjui https://github.com/idursun/jjui
- koakuma-chan 1y ago
  Oh --colocate is what I needed.
  - nchmy 1y ago
    Yup! And you can just do jj git init --colocate in an already-cloned repo and it'll start working immediately, seamlessly. No need to re-clone it via jj git clone --colocate

eulgro 1y ago

I've never tried jj, but recently I discovered lazygit which in my opinion comes pretty close to perfection. Rebasing can be done instantly (reorder commits, fixups, squash), I can extract and reverse custom patches from previous commits, I can partially stage files, undo. One think I like is that it explains what it does in terms of git commands. So it helps a little to have a good git mental model, and as such I guess it doesn't solve the same thing as jj.

xcubic 1y ago
This is the reason I have not gone the jj way.
lysp 1y ago
There is lazyjj which follows a similar theme. Haven't used enough of either to give a good comparison other than lazyjj being earlier in its journey.

deleted 1y ago

[deleted]

simonmic 1y ago

That's a very clear up-to-date intro, great work.

emresahin 1y ago

I tried jj a few days but I noticed my lazygit based workflow and scripts already make me productive enough not to deal with another mental model. jj looks cool in general, I'd start with it if I were just going into this _version control_ thing but for most of us older folks, that doesn't provide enough motivation to change.

stavros 1y ago
Eh, I can see how, if you use GitButler, the porcelain is fairly irrelevant to you, but a few days ago I decided to try Jujutsu, asked Claude how I could do a few things that came up (commit, move branches, push/pull to Github). It took me ten minutes to become proficiend in Jujutsu, and now it's my VCS of choice. I still use Lazygit for the improved diffing, but, as long as you don't mind being in detached HEAD all the time, there's really no issue with doing that. JJ interoperates fine with git, but why would I use the arcane git commands when JJ will do the same thing much more straightforwardly? Also, the ability to jump from branch to branch with all my uncommitted files traveling with me is a godsend. Now I can breeze between feature development, bug fixing, copy changing, etc just by editing the commit I want. If I want multiple AI agents working on that stuff, I just make a worktree and get on with it. Not to mention that I am really liking the fact that I can describe changes (basically add commit messages) before I'm done with them, so I can see them in the tree. JJ is just all around great.

exclipy 1y ago

I tried it for a bit and went back to git-branchless (https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless). git-branchless is just a better set of tools for working on a git repo so local tools like the JetBrains git integration will work just fine. It operates on a similar philosophy to Jujutsu (make it easy to manipulate the commit tree) and the authors did exchange ideas with each other.

KingMob 1y ago
It seems like a lot more than they "did exchange ideas". Arxanas, the lead dev of git-branchless, is also one of the major devs and maintainers of jj. He's active on the jj discord, and just last month put out a call on github for a jj side conference during Git Merge 2025.

tomasyany 1y ago

Don't want to sound old school, but git works perfectly fine. The learning curve might be a bit difficult, but afterwards everything makes sense. And let's be honest, you just need a few actions (pull, add, reset, branch, commit) to use it in 95% of the cases.

tapirl 1y ago
just when you face some unusual situations ...
killerstorm 1y ago
If you work in a team you need to understand rebasing and squashing, unless you can convince team to never use these features. A lot of people are religious about rebasing, "clean" commit history. But it's pretty much incompatible with several devs working on a single branch. I.e. when you work on something complex, perhaps under time pressure, git habits bite you in the ass. It's not fine.
- km144 1y ago
  A lot of the time, multiple devs working on a single branch can be avoided via different decisions made upstream about work that needs done. If my job included more git wrangling as one of my daily tasks I would probably hate my job.
- Cthulhu_ 1y ago
  As soon as you have the situation of multiple people working on the same branch, forbid force pushes at all times. But it's better to avoid that in the first place, all work should be on its own branch at all times. For larger features we often have a feature branch with merge requests for various task branches. Limits the review sizes as well. Of course, you can also then consider to use feature toggles, so there's no feature branch but just your main branch.
- alexjplant 1y ago
  > A lot of people are religious about rebasing Years and years ago I worked on a team where linear commit history was required so every time a merge happened you had to manually rebase and push to Bitbucket. I put a PR in halfway through the sprint, rebased it a dozen times as everybody else's work got merged, and had nothing to show during review because nobody bothered to check mine and the only coworker I had in the same physical office was out on vacation. When I interview for new roles I always make a habit of asking how work gets done to avoid shops that engage in these types of shenanigans.

kavenkanum 1y ago

If only it was supported by Gui tools... I don't bother use Git from my terminal, but use GiFork instead. As I understand there is nothing that may be interesting for me in my scenario...

Aerbil313 1y ago
I actually find I don't need to use any GUI tools with jj because I can actually understand what's going on under the hood since the mental model is much simpler. It helps that jj has excellent visualizations straight in the terminal.

d4rkp4ttern 1y ago

Curious are there nice terminal tools for JJ similar to magit or GitUI?

drew_h 1y ago
https://github.com/idursun/jjui https://github.com/idursun/jjui is absolutely fantastic. One of the best TUI's ever created IMO

prokopton 1y ago

I don’t see anything about side control in this post. 3/10.

o140445 1y ago

[dead]

lillecarl 1y ago

My NixOS repo checkout(s) are always cursed with unstaged changes, will jj help me cure this? Sometimes I feel like "this shit is too bad to commit but it does the plumbing for the thing I'm working on right now" and it ends up untracked for weeks... This is just my personal ADHD pool of code but it gets really gnarly before I take care to dissect my unstaged changes into the repo.

incognito124 1y ago
Almost certainly. I have a private monorepo where I just try things out in new empty changes and I just leave them hanging

rootnod3 1y ago

Hands down one of the best features in jj is undo. In Git, undoing things is always a bit of an open heart surgery, with different commands depending on what you fucked up. In jj? Just a simple jj undo, done. That alone is a killer feature. Then having the whole thing being kinda agnostic by design to the backend system, that is also a sweet spot. I can comfortably use jj locally without any of my teammates knowing that I use jj instead of git.

vander_elst 1y ago

I've been using JJ as my daily driver for ~6 months. It is so nice to be able to immediately rebase everything on top of everything, undo last command, restore a previous state, ignore and postpone conflict resolution. It is such a boost in productivity!!

reddit_clone 1y ago

Hmm. Here I thought it was about a special martial art variant for chair bound developers !

reddit_clone 1y ago

Went through the whole article. Tried out some commands. I haven't 'got' it yet. I am sure I will after some regular use. But being a long time Magit user, its hard to move to anything else.

ephimetheus 1y ago

So far whenever jujutsu came up I didn’t find its features that convincing relative to git. I have to say however that the mega merge workflow seems intriguing and might in fact be a solution to having to serialize my work like I do in git for now. I think I’ll look into that.

palata 1y ago

A killer feature for Jujutsu would be to make the email workflow cool again: https://github.com/jj-vcs/jj/issues/4438 https://github.com/jj-vcs/jj/issues/4438

brainzap 1y ago

I still dont get it, can nobody explain it properly