Steve's Jujutsu Tutorial

Martin (the jj creator) recently gave a talk at the Git Merge 2024 conference: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;LV0JzI8IcCY?si=Pun7WJp4ZWvHq-3G" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;LV0JzI8IcCY?si=Pun7WJp4ZWvHq-3G</a>

Been using jj at work for months now. In colocated mode, JetBrains IDEs even retain some if their VCS integration.<p>The ability to easily work on top of an octopus merge and then push changes &quot;down&quot; into the contributing branches has been a live saver when my team had to do a big refactoring in a mono repo and split the changes into small PRs for individual teams (code owners).<p>The auto committing behavior is a bit weird at first, but now I don&#x27;t want to go back to git. It feels a bit like the step from SVN to git back in the the day. (&quot;this feels weird&quot; -&gt; &quot;how did people ever tolerate the old way?&quot;)

&gt; I also heard friends rave about &quot;stacked diffs&quot; but struggled to understand what exactly was going on there. Nothing I read or conversations I had have clicked.<p>I wonder what it is about descriptions of stacked diffs that doesn&#x27;t land - it&#x27;s literally just a rebase-centric workflow instead of the merge-centric workflow popularised by GitHub et al.

Steve, I see you’re in this thread. I was using jj for a while before reading your tutorial and yet still found it quite insightful and helpful. Thanks for your contribution!

I am torn between sapling and jj. Both make good progress in git&#x2F;github integration which seems to have been the major road block in adoption before. One other major roadblock seems to be the limits of review tools supporting stacks: github PRs are too limited, gerrits ux is horrible, graphite does not work and is not open enough, saplings review tool is just a very slow performing POC (though with a really good UI concept as starting point)

One of my favorite people talking about my single favorite tool of the past 3+ years. Up there with (above, really) zellij and helix for changing my daily life.

Love it, read a couple of chapters already and planning to finish the rest. As a person completely new to jj and someone who also enjoys git CLI, this is an intuitive, very useful and enjoyable read.<p>I’m especially interested after learning about the git compatible backend:<p>&gt; There&#x27;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 anyone else you&#x27;re working with to convert too.

I really like Jujutsu but I went back to Git because there wasn&#x27;t a Neovim plugin with features comparable to Neogit or Fugitive.<p>I even started writing one but that was a pretty big project and I lost the motivation for it.

This was informative, thanks Steve! The only problem I had was that the difference between changes and commits wasn&#x27;t clarified enough in the beginning, and I got lost trying to distinguish between the two. I&#x27;m on chapter 4 and I&#x27;m still not sure what a change is and what a commit is.<p>From a tiny bit of previous jj experience, my mental model is &quot;a commit is the snapshot, and a change is what happened between snapshots&quot;, but that might be wrong. It would be great if this could be clarified a bit more in the tutorial.

I’ve started to use jj much more often (and actually used this tutorial to get me started!). I do wish its interaction with Nix flakes is less annoying though, but that’s not the fault jj.

I get that naming is one of the hardest problems in computer science, but naming software after a martial art is just lazy and will lead to problems with things like searches

Would be great if it was Pijul that got Steve&#x27;s attention. Sometimes it&#x27;s all you need to achieve a lot.

Can someone sometimes use jj and sometimes use git in the same repo?

Steve wrote this in a very approachable style. It is the first time I really understood what &#x27;jj&#x27; is about. I&#x27;m actually kind of excited to start using this tool with my git repos.

I’d love a Sapling vs JJ comparison post. I use Sapling at the day job and… it’s pretty dang good! Although I don’t see how I’d recommend it outside of Meta.<p>I swear the modern programmer doesn’t realize how extremely bad Git is. It does do a lot of things better than SVN. But it’s a long, long ways from “good” imho.<p>I blame GitHub. Git didn’t win because it’s good. Git won because GitHub won. If only HgHub had won instead, alas.<p>My dream VCS system would have a virtual file system, copy-on-write storage, and a system wide blob cache. The goal being to allow open source repos to commit *ALL* their dependencies, up to and including toolchains in many cases.

It&#x27;s my first time encountering your writing Steve, loved it! Time to give JJ another crack...

thank you steve, i’ve been excited for this!

Came here for a martial arts tutorial, which I thought was a bit weird to see front page on HN, and now I see an alternative to git.<p>I don&#x27;t particularly like git and for personal projects use fossil instead.<p>Without going through the whole tutorial, and doing a lot more reading, why should I consider using this over fossil?

I expected actual Jujutsu :)<p>I recommend looking up Bartitsu (that Conan Doyle spelled Baritsu), a short-lived but very interesting martial art.

Jujutsu is terrible in my opinion. people hate the index, but I think they just dont get it. to me a commit is something that is ready to push, and the index is for stuff that is done but not ready to push. just because I wrote one line that I am happy with, doesn&#x27;t mean I am ready to commit and push that. I prefer to add stuff thats done, then when enough is done I can commit and push. if you remove the index it makes it too easy to push half done stuff