GoKawiilReviewing large changes with Jujutsu
I’ve been using Jujutsu ( jj ) as a replacement for Git for the past 6 months or so. Much has been said about it already, which I don’t feel like repeating, so I’ll just say: I’m hooked. It feels like I’ve grown an extra arm when it comes to crafting clear and reviewable pull requests, and I’ve been able to adopt it without my colleagues needing to.
My general coding workflow depends a bit on context—such as the size of the change I’m making—but frequently looks a lot like the squash workflow. If you haven't explored jj already, there are a lot of really good articles about it that I'd recommend reading.
Recently I’ve started to cultivate a new workflow while reviewing code. With the growing use of coding agents, the size of pull requests seems to be increasing. Whether or not that’s a good thing is another matter, but I still need to stay abreast of the new code being introduced, and for now, therefore, I need to review it.
At work, Bitbucket Data Centre is currently the Git “forge” being used. It actually works pretty well with jj because it shows you an interdiff on a PR when you edit a change and push it again. However, one area in which it’s a bit lacking compared to something like GitHub is that it isn’t very easy to track which files you’ve already viewed and were happy with. This adds a lot of friction for a large change where you frequently need to jump around between files.
With a smaller pull request, it’s easy enough to keep the full context of a change in my head, and step through fairly linearly. When it comes to a larger change, especially when you don't yet understand the overall structure of the code, it becomes very tricky to navigate and gradually sign off portions of the code you’re happy with. Furthermore, if you know you're going to have to keep in your head the context of what you've already looked at and what you are still yet to, you're more inclined to put off the review until you've got a chunk of time free.
The new workflow I’ve come up with to address this is:
Duplicate my colleague’s change with jj duplicate and "check it out" with jj edit Create a new empty change before this new duplicated one with jj new --no-edit --insert-before @ Review the code and gradually squash pieces of it into the parent change until there is nothing left
This allows you to track progress through the review using familiar jj diff --stat commands, and to squash hunks or entire files when you’re happy with them. You're also free to switch away and do something else at any point, knowing that things will be as you left them when you come back.
A benefit of this method is it naturally means you’re in your familiar coding environment as you do the review. You are using the same IDE, tooling, and commands as when you’re the one writing the code, without needing to context-switch back to the pull request to mark files as viewed. Of course you do need to move back to the web UI at some point in order to leave comments, but I hope to improve that at some point.
... continue reading