Reviewing Large Changes with Jujutsu | Hacker News Reader

Reviewing Large Changes with Jujutsu

ben.gesoff.uk

108 pointsbengesoff16 comments

A reasonably cool part about this approach (duplicating the commits, though I suppose you could just add your own bookmark on the existing commit, too) is that you can easily diff the current pr state with what you last reviewed, even across rebases, squashes, fixups, etc. Will have to give that a go.

Unfortunately GitHub still doesn't make that easy, and branch `push --force`'s make it really hard to see what changed, would be amazing if they ever fixed that.

In general, I think with the rise of agentic coding, and more review work, I hope we see some innovation in the "code review tooling" space. Not AI reviewers (that's useful too but already works well enough)! I want tools that help the human review code faster, more effectively, and in a more pleasant way.

Of course can't end the comment without the obligatory "jj is great, big recommend, am not affiliated, check out the blog post I wrote a year ago for getting started with it[0]", ha! I'm still very happy with it, no going back.

[0]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...

In git you could compare to the version prior to the latest fetch:

    git diff origin/master@{1} origin/master

or if you vaguely know the time:

    git diff origin/master@{5.weeks.ago} origin/master

> I hope we see some innovation in the "code review tooling" space.

There's some things happening, for sure, but GitHub working towards finally supporting Stacked Diffs will, I hope, accelerate the general demand for better things.

For what it's worth, I've been doing basically this with magit for years now, sometimes with the two-commit setup but usually just using the index plus top commit instead. It's not as slick, though, so this is on my list of things to try out when I give jj a spin eventually.

`c F` in the magit menu squashes staged changes directly into a commit in the log, and `c e` amends (which is to say squashing into the tip). So in this case I'd hit `s` to stage, and either `c e` or `c F j C-c C-c` (fixup, move one item down to get to HEAD^, confirm) — both of which are practically atomic operations for me at this point.

Please. Someone create a decent jujitsu porcelain like magit before I create a shitty one myself. I would rather not subject the world to that.

I have been working on a 100% vibe-coded magit-style jujitsu porcelain for neovim. I cannot emphasize "vibe-coded" enough -- I have not read a single line of code here, nor do I know much about neovim development in general. All that said, it's been working pretty well for me the last couple weeks!

https://github.com/micahbf/maju.nvim

I have been using https://github.com/idursun/jjui a lot and it has been great. Not sure how it compares to magit though.

I’ve been using it too, definitely recommend!

Same for me originally (years past) CLI git, then magit and more recently lazygit. Identical workflows across all 3 tools, with only progressively fewer keystrokes.

I haven't tested it, but this should be slightly simpler, and work better for subsequent review iterations (reviewing what changed once PR is updated):

    jj new main -m review
    jj new -m pr
    jj git fetch
    jj restore --from=big-change@origin .

Then keep squashing from `pr` to `review` as described in the article. When the PR gets a new version, rerun the last 2 commands.

This would avoid dealing with merge conflicts when the PR changes, which is nice.

This is very nice, I just tried it, thanks for the suggestion. I was messing around with rebasing subsequent PR updates onto the review commit but it got a bit messy with conflicts. The `jj restore` should solve it

This sounds great, I'll have to try this. Though I would expect to do it slightly differently: duplicate the change, do a simple `jj new -m review` on top of it, the `jj squash -i --from @- --into @` to pull in each reviewed chunk. As in, exactly the same thing but the working copy would be the review change instead of the gradually dwindling original change.

I guess I can see the appeal of working until there's nothing left, but you get that either way -- in my scheme, you go until there's nothing left to review in the original duplicate change, instead of in the working copy.

I guess it's not very different. Either way, you could use multiple review changes if the thing you're reviewing has several independent concerns tangled together (likely if the author is using git not jj!). I think mine might work slightly better if you get distracted and make some other unrelated change or a logging/debugging change to better understand the patch. That would get mixed into the patch you're trying to empty out with your scheme, but would stay in a review change with mine. (And obviously, you can always squash/split it somewhere else after the fact in either scheme, it just takes a manual step.)

Thanks for the feedback! The reason I like having the duplicate change as the working copy and squashing it down into the review change is that with colocated Git mode, my IDE highlights all the working copy changes as if they were uncommitted changes. Then I can easily see how much I’ve got left whether I’m in the terminal or the IDE. Good point about mixing in unrelated changes though, your way saves a step there I think.

I use Jujutsu in mostly the same way at work. I have a `jj review <branch or PR number>` alias that checks out a copy, and then I do the review with three copies open: the IDE (for quick navigation and LSP integration), the diff (i.e `jj diff` with a nice pager), and prr [1] so I can leave comments directly from my editor.

[1] https://github.com/danobi/prr

Thanks for telling me about prr, I've always wanted something like this!

Reply on news.ycombinator.com