What I've learned from jj

&gt; <i>The idea, particularly as realized in the GitHub pull request workflow, is that the real “unit of change” is a pull request, and the individual commits making up a PR are essentially irrelevant.</i><p>I <i>loathe</i> GitHub PRs because of this. Working at $dayjob the unit of change is the commit, and every commit is reviewed and signed off by at least 1 peer.<p>And you know what? I love it. Yes, there&#x27;s some overhead. But I can understand each commit in its entirety. I and my coworkers have caught numerous issues in code with these single-purpose commits of digestible size.<p>Compare this to GitHub PRs, which tend to be beastly things that are poorly structured (not to mention GitHub&#x27;s UI only adding to the review problems...) and multipurpose. Reviewing these big PRs with care is just so much harder. People don&#x27;t care about the commit message, so looking at the git log it&#x27;s just a mess that&#x27;s hard to navigate.

I began using Jujutsu as my VCS about 2 months ago. Considering most of my work is on solo projects, I love the extra flexibility and speed of being able to safely fixup recent commits. I also love not having to wrangle the index, stashes, and merges.<p>`lazyjj` [1] makes it easier to navigate around the change log (aka commit history) with single keypresses. The only workflow it&#x27;s currently missing for me is `split`.<p>For the times when I have had to push to a shared git repo, I used the same technique mentioned in the article to prevent making changes to other developer&#x27;s commits [2].<p>It&#x27;s been a seamless transition for me, and I intend to use Jujutsu for years.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;Cretezy&#x2F;lazyjj">https:&#x2F;&#x2F;github.com&#x2F;Cretezy&#x2F;lazyjj</a> [2] <a href="https:&#x2F;&#x2F;jj-vcs.github.io&#x2F;jj&#x2F;latest&#x2F;config&#x2F;#set-of-immutable-commits" rel="nofollow">https:&#x2F;&#x2F;jj-vcs.github.io&#x2F;jj&#x2F;latest&#x2F;config&#x2F;#set-of-immutable-...</a>

Huh, reading the penultimate &quot;“Units of change” and collaboration&quot; section reinforces the feeling that Github PRs really are a poor way to do code submission&#x2F;review, and have been holding back a lot of the industry from better ways of working for a long time.

JJ just surpassed a milestone for me personally where there were no hick-ups for more than 6 months and it feels genuinely superior to git and also to sapling for performance, stability and UX. If you ever considered switching i think it might be now. Colocated mode does not feel like a second class citizen and works really well too so there is always the option to use a sophisticated git client like fork for certain tasks. VisualJJ is also a great albeit not open source vscode extensio n that is slowly catching up to ISL. (If you are used to ISL and think visualJJ looks empty and lacks features: most things are hidden in the context menu which takes some getting used to.)

Surprised no one has mentioned <a href="https:&#x2F;&#x2F;graphite.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;graphite.dev&#x2F;</a> yet. Our team uses it for stacked PRs, and it works really well.

This article covers my own experience with JJ very accurately. I&#x27;ll even go as far as to say that if had to write my own article about jj, I&#x27;d use exactly the same talking points and examples. Great writeup

I would really love a comparison between JJ and fossil. I use fossil for personal projects instead of git. So I&#x27;d like to know if I should consider JJ.

Nice writeup -- had been wondering about how it compares to Git (and any killer features) from the perspective of someone who has used it for a while. Conflict markers seems like the biggest one to me -- rebase workflows between superficially divergent branches has always had sharp edges in Git. It&#x27;s never impossible, but it&#x27;s enough of a pain that I have wondered if there&#x27;s a better way.

Like the author, I&#x27;d appreciate a stacked PRs <i>approach</i>, integrated with GitHub (unfortunately). E.g. `a → b → c → d` where I have PRs open for `b`, `c` and not yet on `d`, that are &quot;linked&quot; to the jj changes. So 1 change per PR or it could even be multiple. I&#x27;ve lately become a huge fan of git-spice, that <i>just works</i>.

When I&#x27;m developing I inevitably fix one thing after another as I pass through the code. What I&#x27;d like is a tool to take such PRs and automatically split it up into loosely coupled, cohesive chunks.

&gt; You don’t need to explicitly tell jj about what you’ve done in your working copy, it’s already tracked. This removes the need for an “index” or staging area<p>Does this mean that you have to proactively remember and undo any config file changes you made e.g. while fixing an issue in a test environment? Sounds a little risky.

&gt; If I had s -&gt; t -&gt; u -&gt; v and wanted to reorder them, it’s as easy as jj rebase --revision u --after s, and I’d end up with s -&gt; u -&gt; t -&gt; v,<p>How did t end up after u?<p>I&#x27;d expect that to fork into (s -&gt; t) and (s -&gt; u -&gt; v). Either that or maybe (s -&gt; t -&gt; v) and (s -&gt; u).

I&#x27;ve tried out jj a little bit personally, but without exaggeration I am using git submodules in every single &quot;real&quot; project I&#x27;m actually working on, so lacking support for submodules is a complete non-starter for me :&#x2F;

As entrenched as git is, I feel like its only a matter of time until it&#x27;s dethroned.<p>The basic workflow is fine. And there are some very powerful features. But then you try find the parent of a given branch and you&#x27;re left wondering how the f#!@ thats so hard.<p>It&#x27;s definitely nit picking. It&#x27;s probably 85-90% of what you want it to be. But there is definitely enough room for improvement to warrent moving beyond it. I think the workflows and integratoins (github, gitlab, etc.) make it stickier as well. I just dont think we should assume everyone is just going to use git for the next 20+ years.

I often have &quot;no changes&quot; in my Codespaces, because I haven&#x27;t committed then yet.<p>Would be nice, if Codespaces keeps the JJ change stored somewhere, so it isn&#x27;t tied to the lifetime of the machine.

Jujutsu - I like the name.<p>I often see programming as going MMA with data, until you get what you want out of it.<p>Using brute force algorithms is going berserk, vibe coding is spamming summons in hope they get the job done, etc.

Skimmed the article so I admittedly can&#x27;t speak to much to the content of it, but just wanted to give my 2c on working on individual things after spending a lot of time working with a stack-based VCS in mercurial&#x2F;sapling -- jj felt pretty hard to get used to and after a couple of weeks I gave it up. I think it needs a competitive visualization tool to Interactive Smartlog.<p>I&#x27;ve settled on using Interactive Git Log in VSCode.

Sounds a lot like what’s being used internally at Google

A thing to learn from JJ&#x27;s performance is that not everyone is cut out to direct Star Wars movies.

i&#x27;m growing tired of these git alternatives.<p>I feel like people should just learn to use git.

It’s clear from multiple posts over years that jj has a better UX than plain git.<p>Why not just merge it into git?

I used jj for a bit. It messed up my code, put everything in staged and what not. I might try it again when it&#x27;s stable.

I&#x27;ve been using jj, but am considering going back to plain git now because all the latest llm tools know git and not jj. I don&#x27;t recommend spending time on it now.