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