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.
> 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.
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.)
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.
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.
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.
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...
> 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.
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.)
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 haven't tested it, but this should be slightly simpler, and work better for subsequent review iterations (reviewing what changed once PR is updated):
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.
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