What is jj and why should I care?
by tigerlily on 4/14/2026, 10:33:39 AM
https://steveklabnik.github.io/jujutsu-tutorial/introduction/what-is-jj-and-why-should-i-care.html
Comments
by: zingar
"It's more powerful and easier" is a great claim, but I need examples in this opening page to convince me of the pain I could save myself or the awesome things I'm living without.
4/14/2026, 2:07:43 PM
by: tiborsaas
Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow.<p>I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state.<p>Since it's git compatible, it feels like it must work to add files and keep files uncommitted, but just by reading this tutorial I'm unsure.
4/14/2026, 12:54:18 PM
by: tom_alexander
I'm giving jj a try but one aspect of it I dislike is edits to files are automatically committed, so you need to defensively create empty new commits for your changes. As in, want to browse the repo from a commit 2 weeks ago? Well if you just checkout that commit and then edit a file, you've automatically changed that commit in your repo and rebased everything after it on top of your new changes. So instead you create a new branch off of the old commit and add an empty commit to that branch so any file changes don't end up rewriting the past 2 weeks of history. git is much nicer in that I can do whatever I want to the files and it won't change the repo until _I tell it to_.
4/14/2026, 12:01:17 PM
by: kevin_nisbet
I really wanted to like JJ, it was handy for a few months when I used it. But for me in the end I reverted back to regular git.<p>What triggered me to go back was I never got a really clean mental model for how to keep ontop of Github PRs, bring in changes from origin/main, and ended up really badly mangling a feature branch that multiple contributors were working on when we did want to pull it in. I'll probably try it again at some point, but working in a team through Github PRs that was my main barrier to entry.
4/14/2026, 2:29:56 PM
by: dgb23
The last paragraph might be the most important one:<p>> There's one other reason you should be interested in giving jj a try: it has a git compatible backend, and so you can use jj on your own, without requiring anyone else you're working with to convert too. This means that there's no real downside to giving it a shot; if it's not for you, you're not giving up all of the history you wrote with it, and can go right back to git with no issues.
4/14/2026, 11:51:08 AM
by: jrockway
jj is great and while it was an adjustment at first, I've never looked back. I feel like when you're working with other people, things never get reviewed and merged as quickly as you'd like. With jj, it's pretty low-cost to have a bunch of PRs open at once, and you can do something like `jj new <pr1> <pr2> <pr3>` to build stuff that requires all 3. This lets me do things like... not do a big refactoring in the same PR as adding a feature. I can have them both self-contained, but still start on the next step before they're all merged. It's easy to add changes on top, switching between the individual PRs as comments come up, etc.<p>I always liked doing things like this. At Google where we used a custom fork of Perforce, I told myself "NEVER DO STACKED CLs HAVE YOU NOT LEARNED YOUR LESSON YET?" If one CL depended on another... don't do it. With git... I told myself the same thing, as I sat in endless interactive rebases and merge conflict commits ("git rebase abort" might have been my most-used command). With jj, it's not a problem. There are merge conflicts. You can resolve them with the peace of mind as a separate commit to track your resolution. `jj new -d 'resolve merge conflict` -A @` to add a new commit after the conflicted one. Hack on your resolution until you're happy. jj squash --into @-. Merge conflict resolved.<p>It is truly a beautiful model. Really a big mental health saver. It just makes it so easy to work with other people.
4/14/2026, 2:20:46 PM
by: justinmayer
Many folks aren’t aware that there is also an open-source, cross-platform desktop GUI application for Jujutsu called GG: <a href="https://github.com/gulbanana/gg" rel="nofollow">https://github.com/gulbanana/gg</a><p>I mention it because while the <i>jj</i> command line interface is excellent, there are certain tasks that I find easier to perform with a graphical user interface. For example, I often want to quickly tap on various revisions and see their diffs. GG makes that kind of repository browsing — and certain squash operations — much more efficient for me.<p>If you’re interested in more information about GG, my co-host and I talked about it in a recent episode of the Abstractions podcast at about the 8:17 mark: <a href="https://shows.arrowloop.com/@abstractions/episodes/052-they-deserve-the-dunks" rel="nofollow">https://shows.arrowloop.com/@abstractions/episodes/052-they-...</a>
4/14/2026, 2:01:24 PM
by: wolttam
What happens when jj introduces this native repository format - break compatibility with all the popular git hosts?<p>If jj is so great <i>now</i> and works with git as a backend, it’s tough to imagine why it’s worth pursuing a native and presumably incompatible backend.
4/14/2026, 2:27:48 PM
by: BeetleB
One of my favorite jj features is "jj absorb".<p>For each change you've made in the current revision, it finds the last commit where you made a change near there, and moves your changes to that commit.<p>Really handy when you forgot to make a change to some config file or .gitignore. You just "jj new", make the changes, and "jj absorb". No need to make a new commit or figure out where to rebase to.
4/14/2026, 2:12:21 PM
by: qezz
For those, who want to/need to keep some files uncommitted, the workaround I found is to put gitignore into some nested directory:<p><pre><code> mkdir junk echo '*' > junk/.gitignore </code></pre> jj won't track those files under ./junk/<p>Also might be relevant for claude, since it wants to put its settings into the repo itself as `.claude/`:<p><pre><code> mkdir junk/.claude bwrap ... --bind "$(pwd)/junk/.claude" "$(pwd)/.claude" ... </code></pre> For some more common files, I use global gitignore file as<p><pre><code> # ~/.gitconfig [core] excludesFile = ~/gitconf/gitignore_global # ~/gitconf/gitignore_global .envrc .direnv/*</code></pre>
4/14/2026, 1:46:50 PM
by: ferfumarma
Can jj iterate through a list of repositories and clone them all to local storage?<p>It isn't very hard to make a bash script to do it, but I have about six github repos, all of which frequently need to be put on a new machine. that kind of functionality would be cool to have out of the box.
4/14/2026, 2:04:08 PM
by: QuiDortDine
> $ cargo install jj-cli@0.23.0 --locked<p>I won't install Rust just to test your software. Make a debian package like everyone else.
4/14/2026, 2:17:13 PM
by: mi_lk
Please update the "Stacked PRs" workflow article Steve...
4/14/2026, 2:10:28 PM
by: shuyang
Has anyone found a good code review workflow with `jj`? My problem is that GitHub doesn't remember the content of the last reviewed SHA, so every time I push a new change from jj, reviewers lose the delta from their last reviewed commit.<p>To work around this I stopped moving revs (squash/rebase) after review starts, which creates awkward local graphs if I have to merge from main for merge conflicts. Graphite works but it's $$$, and phabricator/reviewable/gerritt all have significant onboarding hurdles.
4/14/2026, 12:26:17 PM
by: randyrand
jj sounds awesome. I think I’ll give it a shot.<p>But I found this article a bit long winded and ended up asking an LLM about it instead.
4/14/2026, 2:19:22 PM
by: swoorup
I love jj, but mostly I use jjui.<p>I would like more uniformity in the way jjui handles commands when you are viewing changes vs when you are viewing files within a single change.<p>Often I just make my changes and leave it there without `new`, as I am not sure which file should go in a single commit. I just leave it there and I interactively commit later.<p>For me to use `new` more, I would like the ability to also simply be able to get a tree view of all changes, which contains file which contains file changes, so I could can have marks that span multiple changes and then either `split` or `commit` or `squash` the change, idk if there is a good word for it. Right now I can only mark within a single change, and I lose it once I navigate up.
4/14/2026, 12:38:15 PM
by: aftbit
Nope, git is good enough, and is the global standard. We don't need more new VCS.
4/14/2026, 2:01:04 PM
by: enbugger
1) Are there any benefits in replacing a personal private project git repo with jj? I usually just commit straight to master in order to just not to lose the changes and be able to roll back. 2) Are there any pros in doing so in a project with many large binary files (3d models, images)?
4/14/2026, 12:46:47 PM
by: rob74
Still not finished unfortunately :( Guess Steve is currently busy writing the next big thing in programming languages (<a href="https://steveklabnik.com/writing/thirteen-years-of-rust-and-the-birth-of-rue/" rel="nofollow">https://steveklabnik.com/writing/thirteen-years-of-rust-and-...</a>) ?
4/14/2026, 12:21:39 PM
by: andrepd
Is there a <i>concise</i> introduction / overview of jj? I've read 8 pages of this link and the author is still in preambles and considerations... Not my favourite style of article!
4/14/2026, 12:50:19 PM
by: PUSH_AX
If it ain't broke...
4/14/2026, 12:38:20 PM
by: demorro
This doesn't seem different enough to be worth the transitional cost, even if you don't need to actually move away from a git backend.
4/14/2026, 1:15:25 PM
by: nailer
JJ might be good (this article couldn't convey why in the "What is jj and why should I care?" page) but it's not 10x better than git, so it will likely die. Sorry, nothing personal, Mercurial/hg was a little bit better than git and died too. Network effects.<p>What has a change is ast-based version control.<p>You adding a feature to a function that uses a struct I renamed shouldn't be a conflict. Those actions don't confliuct with each other, unless you treat code as text - rather than a representation of the logic.<p>Ending merge conflicts <i>might</i> make a new version control 10x better than git, and therefore actually replace it.
4/14/2026, 1:59:14 PM
by: scotty79
Does jj have partial clones of remote repo?
4/14/2026, 1:38:25 PM
by: SV_BubbleTime
>You can request to not use the pager by using jj st --no-pager, or if you hate the pager and want to turn it off, you can configure that with<p><pre><code> $ jj config set --user ui.paginate never </code></pre> In one feature they can’t help themselves from calling it two different things already.<p>Why do this? Why can’t the very clearly smart people making things step 1/2 step outside themselves and think about it like they are the users they want?<p>Earlier they talk about the native format and how it isn’t ready… so that to start you need<p><pre><code> jj git init </code></pre> … but… if they’re planning a native format that makes no sense as a command. It would be ‘jj native init’ later?<p>Early planning keys/plans imo but those rarely change so as to not accept your early adopters.<p>These seem like small things but to me it’s a warning.
4/14/2026, 2:12:53 PM
by: palata
I tried jj for a few months. It was fun to learn a new thing, but I haven't had a single case of "wow, this would have been a pain with git". Then I went back to git (it's been 6 months now) and I haven't had a single case of "this is so painful, I wish something better existed".<p>So it felt like the XKCD on "standards": I now have one versioning system, if I learn jj I will have two. What for?<p>Don't get me wrong: it's nice that jj exists and some people seem to love it. But I don't see a need for myself. Just like people seem to love Meson, but the consequence for me is that instead of dealing with CMake and Autotools, I now have to deal with CMake, Autotools and Meson.
4/14/2026, 1:11:13 PM
by: ux266478
Clicked on this hoping it would be the irc client, very disappointed!<p>For those in the know, how does jujutsu stack up to something like Darcs?
4/14/2026, 2:12:04 PM
by: butlike
FWIW, it's a pretty decent fried fish chain in Chicago as well.
4/14/2026, 12:42:52 PM
by:
4/14/2026, 1:04:32 PM
by: dhruv3006
this looks pretty interesting.
4/14/2026, 12:43:30 PM
by: tucnak
16 year-old me would have been very impressed by this!
4/14/2026, 11:54:55 AM
by: blacknig
[flagged]
4/14/2026, 12:44:02 PM
by: cynicalsecurity
[flagged]
4/14/2026, 12:23:47 PM
by: jansan
We all need to give ourselves a push and finally make the next step in version control. Github, Google, Microsoft, Meta (did I forget anyone relevant? Probably) should just join forces and finally make it happen, which should not be a problem with a new system that is backend compatible to Git. Sure, Github may lose some appeal to their brand name, but hey, this is actually for making the world a better place.
4/14/2026, 11:59:57 AM
by: 7e
Is it better for AIs? That’s the only reason I would care.
4/14/2026, 12:11:19 PM
by: zhaoyongjie
To be honest, JJ is dick in Chinese, literally.
4/14/2026, 2:08:54 PM
by: systems
its almost impossible for me to tell if this better or worst than git i read few things about jj, and my conclusion<p><pre><code> 1. its different 2. very few user would really care about this difference </code></pre> i think git is good (not good enough, good just good, or really good) and unlike shells, i cant think of a reason to have mass migration to it<p>people use zsh because apple choose it, and pwsh because microsoft settled on it, on linux i am sure we can do better than bash, but it good enough and nothing justified replacing it (that being said, all 3 OSes should have settled non nushell)<p>in summary, if we couldnt replace bash on linux, i dont think anyone can replace git, git as an scm tool if far better than bash as a shell
4/14/2026, 1:45:23 PM