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.
1718627440 [3 hidden]5 mins ago
In git you could compare to the version prior to the latest fetch:
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.)
tensegrist [3 hidden]5 mins ago
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.
rirze [3 hidden]5 mins ago
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.
pzmarzly [3 hidden]5 mins ago
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.
CGamesPlay [3 hidden]5 mins ago
This would avoid dealing with merge conflicts when the PR changes, which is nice.
abound [3 hidden]5 mins ago
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.
HN.zip
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...
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.
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.)
`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.
[1] https://github.com/danobi/prr