[sfink]

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.)

[bengesoff]

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.