I think when people ask what’s so great about jj they tend to go deep into things such as mega-merge strategies and stacked PRs. These things are cool, no doubt, but jj can be useful starting from the very small.
In my case as a manager I commit a lot of small stuff, documentation updates, nits, fixes (and also larger bits of code). I got this down to be pretty fast using all the git aliases available.
In an ideal world I’d be doing most of my work in a worktree (which takes ages to create in our monorepo) and I could pass the change quickly in my clean main checkout folder. That would then go like this:
gcb random-new-branch
ga docs.md
gcm "Documentation update" # Or immediately gcam
gpuBut of course as a manager, my life is made out of interruptions so odds are that my main checkout folder is not clean and contains changes for something else I started but did not get to finish. Now I have a bunch of bad options:
- Quickly finish the old work and push it so I can work on the new thing
- Create a worktree for this tiny thing
- Stash the old work and risk forgetting about it entirely
- Think all of the above is too much effort and I’d just rather drop this
- Go to Github.com and pass the change through the web site (best option if I can do it in one go)
With jj I don’t have to deal with most of this. Whenever I have something new I want to work on I can type: jj new main and I’m good to go. Whatever work in progress I might’ve had, has already been snapshotted and will still be there when I want to resume work on it.
And when it’s ready, I can do jj git push -c and it will send my change to our forge without me having to name the branch. I still have to describe the change but all in all jj has turned 4 steps into 2 and removed the potential blockers from this process.
