Evan's Jujutsu Tutorial

The biggest benefit that I've received from jj is a much better rebasing story. My original problem was:

1. A grad student has been working on a branch for four years as part of their thesis
2. Their defense is coming up and they need to merge the branch into main
3. They haven't done any merges or rebases in the last four yours and are thousands of commits out of date.
4. Their expertise is organic chemistry, not necessarily software engineering, so they can't do much beyond git commit or git pull
5. It is now my job to rebase this ancient branch onto main, which will likely take a week or two, since almost every commit will generate a conflict
6. Three days into this rebase, an urgent bug fix request comes through. This requires me to abort the rebase, fix the bug, then start the rebase all over again.
7. By the time I've finally rebased onto main, it's taken three weeks with all the interruptions and I need to perform a new rebase to get onto the current state of main.

With jj, I get the following benefits

1. Merge conflicts are first class, so I can solve them at my leisure, instead of needing to handle them all at once. When the urgent bug fix request comes through, I can pop over and fix that on a new commit without losing any of my progress
2. jj tooling makes rebases go much faster. What would have taken a week to do in git I can do in a day with jj. As one particular anecdote, jj once identified for me two hundred consecutive commits that, combined, did nothing. A colleague had spent two days trying to work tens of thousands of lines of merge conflicts in git, but I was able to just drop the whole group in under a minute.
3. In the middle of the rebase, I can still update main and move the rebased branch onto the latest main without needing to resolve the original rebase.

but ultimately ended up resorting to asking LLMs to help me through the pain of dealing with Git directly

What kind of things are you getting an LLM to help with?

---

My personal experience with git is that I just avoided doing anything that wasn't the rudimentary things you've mentioned. Instead of stashing and switching branch, I'd just re-clone the repo to a different location. Instead of carefully committing relevant changes, I'd just git add --all and commit everything, or undo changes in my editor, commit, then redo them.

At work I used Mercurial for 7 years, and so I was already primed to be more comfortable with JJ—so my time to get comfortable won't be particularly relevant here.

I will now do all those "complicated" workflows of rearranging commits and juggling multiple changes because it's now very easy, whereas before I'd instinctively work around them.

it's a matter of the point of view and of what do you need vcs for.

if all you want to do is to make eventual snapshots of code developed in linear fashion — sure, that's all you need. and, probably, full vcs is overkill anyway and something like dropbox could work for you as well.

for me, VCS is a mean for building a narrative: I want to show how I think about the code, layers of it. the primary audience is colleagues, the secondary is the future me (I often need to read code which I wrote 10 years ago). and jj gives me much more ergonomic toolset for this: less friction 🤷‍♂️

I too used git in a rudimentary fashion. The checkout/add/commit/push modality that I worked in was primarily about safe-guarding and occasionally revisiting.

I think jj changed that for me. It took me a week to internalize all of jj, but since then I am constantly doing the more 'advanced' git activities of rebasing, squashing, cherry-picking.

This 'advance' activity was the kinda stuff that I avoided before, and when I needed it I would copy/paste something from stack-overflow. Mind you I've been using git for 15 years but it's jagged UX never allowed me to internalize the more advanced behavior and have it stick. JJ, again, has changed that.

I'm advocating that if you have been using git as a backup, (I don't want to put words in your mouth that that is what you are doing... but it was primarily how I used it -- on my own projects), that jj may allow you to consider different workflows.

For me, jj has allowed me to craft narratives. JJ changes are chapters that I can edit, re-arrange, abandon. I now have a much more fearless relationship with my code than I did before and this has allowed me to go off on wild goose-chases (or have an LLM chase the goose).

First, I think it’s fine to ask an LLM to help. I did the same until I learned the basic commands I care about. I did read some guides end to end but only to get the basics of terms and function. It took a few days and regular use on a personal project for me to be pretty fluent in the basics. I wouldn’t say I’m a jj hero, but I definitely find it useful and it makes me think about VCS in a different way.

I’ve personally found git stash and in-progress rebase to be excruciating.

When I’m doing a refactor or a larger feature, I usually code my final goal along with all my necessary changes along the way. Once I know my goal and everything I need to do, I split my change into smaller chunks to make reviewing easier and each change set have its own clear justification. Usually it’s “fix all eslint warnings”, “refactor to expose function”, “refactor callsite A to use new function”, “add new feature”

jj split is perfect for this and I use jj because of this one feature.

On the other hand, git stash is super hard to juggle, and is doubly annoying when there’s a conflict because you may just end up losing your stashed code. Too many UX footguns with stash.

Then there’s rebase, if I need to address PR feedback on a lower commit, it’s usually a nightmare to rebase commits or PRs on top, especially in a stacked PR flow. No progress indicator, hard to stop in an intermediate stage, doesn’t restock well. This is why I still use graphite to manage my stacked PRs. It’s just a hard to do it with git

Do you ever put up stacks of 5-50 commits for your coworkers to review? This is a practice that originated in the Linux kernel and has made its way over the years to a lot of professional teams. With git you are made to use git rebase -i; jj is designed for these workflows from the start.

Based off you mentioning your rudimentary workflows and not mentioning rebasing/commit rewriting, you're probably very safe.

jj makes commit rewriting much easier, which is important for many projects that expect "clean"-ish commits.

Are you doing pull requests? You can skip the song-and-dance with creating a branch, putting things into the branch, then pushing.

jj new
<make changes>
jj commit
jj git push --change @-

It'll push a random branch to the remote for you.

It's also amazing for rewriting history using jj desc or jj edit. I find manipulating commits prior to the previous one much easier using jj.

I've found what makes it hard to describe the joys of jj is how implicit things I thought were part of all VCS systems were not true. The atomic actions are so much simpler.

That is why I think people find it hard to come up with a good sales pitch, so "not git" takes the full space from there. I'm one of those people that fails hard at giving a good one too, mind you. :)

I also thought it was one of the best pitch pages for jj I've seen yet:

• It's short and easy to read.
• It starts off with "Don't worry": It's easy to try, and it's easy to stop.
• It has the "simpler and more powerful" tagline.
• It compliments the part of git that has earned it (the data model), so people comfortable with git hopefully don't assume, "This must be for people who hate git".
• It shows several concrete examples of things that are possible to do with git but are just easier with jj.

I don't recall where I saw it, but the one that got me interested in trying it out was "it's git, but you're always in an interactive rebase".

I use the Sublime Merge GUI for git and with some custom commands I can get really close to solving the problems with git mentioned here.

I really recommend Sublime. Unlike other Git GUIs it tries to stay as close to the git commands as possible. Except the inscrutable syntax is now menus and buttons. It doesn't hide them either, each action is a command which gets logged in the status bar.

I'd switch in a heartbeat if there was a Sublime JJ.

I think one improvement would be to mention "Merge conflicts are saved as conflict objects (as opposed to blob objects)" in the conceptual model part