Jujutsu worktrees are convenient (2024)

I don't understand the workflow that makes JJ more useful than git. I dont think I've even had the idea of having multiple worktrees going at once. What is the use case? The author mentions being blocked by CI flow. Don't you have CI running on gitlab or github? just commit and push the branch and run CI. The author mentions stashing the changes, but like.. if you're running against CI, isn't it in a state that is commitworthy? I don't see how creating a worktree in a new folder and opening a new editor is more convenient than creating a branch at a certain commit.

I can understand if you need to run a CI or unit tests locally. Is that it?

I am not attacking JJ, I genuinely can't understand its value in my current workflow.

You push branch A, then switch to branch B and start working on that. CI failed on branch A, so you stash branch B and switch back to branch A to fix it.

"When is jj useful" is a different question from "when are workspaces/git worktrees useful"

I find jj overall most useful for separating the concept of a machine-level commit history that saves every change from a human-readable commit history . jj has really nice tools for cleaning up your commits for review while still retaining all the mechanical changes in case you need to get more granular. (Of course, there are many other tools to do this, like magit – I just find jj to work best with my brain.)

Workspaces/worktrees are best when you have long-running tasks where the state of the disk is important. Local "CI" is a good example – kick off a long test run on one workspace while starting a new task in another. Another example these days is stuff with Agentic LLMs, e.g. I might create one workspace and ask Claude Code to do a deep investigation of why our AWS costs went up.

thanks, that makes sense. I don't see how a worktree is more convenient in that case.

Maybe from the kind of work I do? either CI is failing because of something really simple, or something really complicated that means getting a product setup and producing debug messages. If it's a critical fix on branch A, then I'm not working on branch B. I'm testing branch A locally while CI does its thing

For what it's worth, I have been using jj as my primary git client for two years at this point, and have only use workspaces to see how they work, and then never touched them again.

There is a lot more to jj that makes it nicer than git, but it's mostly a bunch of small things that jj does nicer, that cumulatively add up to a significantly nicer experience.

I wrote a very popular tutorial for jj, and I didn't use workspaces until a few weeks ago. They're useful for the same reasons git worktrees are: most recently, people use them for doing work with multiple AI agents in parallel, but historically, I've seen people use them for things like "this project's build takes 30 minutes so I want to work on something else while I wait for that".

> I don't see how creating a worktree in a new folder and opening a new editor is more convenient than creating a branch at a certain commit.

Worktrees are about being able to work on multiple branches at the same time, fundamentally. When you want to be doing something on one branch and something else on another branch simultaneously.

That does mean it's, IMHO, a fairly niche feature.

I've used multiple worktrees with plain git; it's not a unique jj feature anyway. It's handy for working on multiple things at the same time with somewhat less cognitive overhead to switch back and forth.

I think it shouldn't be, and the poor affordances in git have hidden this for a long time.

What kinds of things do you use it for? I'm always open to learning about newer and better ways to work.

Worktrees are useful particularly because they look like entirely separate projects to your IDEs or other project tooling. They are more useful on larger projects with lots of daily commits. If you just use branches then whenever you switch, in the worst case, your IDE has to blow away caches and reconstruct the project layout or build the project fresh. On large projects this takes significant time. But switching your IDE to a different project, there are now two project and build caches to switch between.

I don't know what JJ brings over git, but what sold me worktrees around 2 years ago was this article: https://matklad.github.io/2024/07/25/git-worktrees.html

Specific workflows that I use in jj vs git:

1. Stacked PRs. I like to be kind to my reviewers by asking them to review small, logically-contained pull requests. This means I often stack up chains of PRs, where C depends on B depends on A, and A is being reviewed. If I receive feedback on A, jj enables me to incorporate that change within A, and flows those changes down into my dependent branches. I can then merge and close out A, whole continuing to work on B and C. Achieving this in raw git is labour intensive and error prone.

2. Easily fix up commits. I like to work with atomic commits, and sometimes I realize that I've made a typo in a comment, or a small error, or missed a test case. Jj makes it really trivial to timewalk back to the commit in question, fix it and resume where I left off.

3. Decompose a big PR into multiple PRs. This is the flip side of point 1: I can take my own big PR and rearrange and partition the commits into A, B and C so that they can easily be reviewed.

In general, jj seems to encourage and reward you for being disciplined with your commits by enabling you to be more flexible in how you stage, review and ship your code.

On the flip side, if you're the kind of person who is used to typing `git commit --all --message "xxx"` you might not get as much value from jj until that changes.

I keep my agent workflows distinct; we have (for historic reasons) a lot of non-git controlled context that differs between branches, and moving all that around on checkouts is untenable. I use this tool:

https://github.com/tdhopper/wt

with some custom shell aliases to make it easier.

ah interesting. our codebase is over 10gb with about 8 years of history. But, we only have 2-3 merges per week.

> I dont think I've even had the idea of having multiple worktrees going at once.

I have a recent annoyance that's solved by work trees: running multiple AI agent instances locally in parallel, without containers or VMs. Jujutsu isn't even needed for this, 'git worktree' is adequate. Granted, self-hosted agents is a niche use case, but IMO, worktrees are the simplest and most elegant way to scale up GPU utilization once the model is loaded. Other alternatives are multiple checkout locations, containers or VMs each requiring a 1:1 ratio to agent instances.

jj is a different topic.

As for worktree, jj or git, it has become the defacto way to work on multiple branches in paralell, using AI. Unlike the non AI workflow where you don't switch often, working with AI involves more branches that can be worked on in parallel and switching back and forth quite rapidly.

I kind of don't get this comment. Isn't the `jj` default behaviour effectively `git commit --all`? There's no staging area -- and I personally find `git add` or `git add -p` a better UI than `jj commit -i`.

Meanwhile, there are git tools that solve the above three problems. My organisation uses `git-spice` (https://abhinav.github.io/git-spice/) which tightly integrates with Github to give you stacked PRs, editing of branches and management of your stacks in Github.

I've been trying jj for a while now because Steve Klabnik heavily recommended it, and so far it hasn't clicked in as nicely as my existing git setup.

I think everyone uses jj a bit differently. Personally I don't like having a staging area; for me it's an opportunity to forget to add a change to a commit. I don't keep files in my work tree that I'm not going to commit or ignore.

But when I first moved to jj I tried to make it work as closely to git as I could. The model I used back then was to have a commit that I meant to upload eventually, and then a working commit on top of that. Then `git commit --all` was `jj squash` and `git commit foo bar` was `jj squash foo bar`.

Eventually I got lazy. It was an extra command, and I almost never have the situation where I don't want to include a file. In the rare case that I do, I'll create a new commit with `jj new` and squash that file into there (you could have a shortcut for it, but the long form is `jj new -m "foo changes" --no-edit && jj squash --to @+ foo`, and then keep working.

FWIW as a fan of git add -p I tend to use the “squash workflow” rather than commit -i.

Thanks, I'll try that :). Despite the fact that I've worked my way back to `git` for my mainline work, I've still got some repos that I've left jj live in to keep picking away at it.