[HN Gopher] Reviewing Large Changes with Jujutsu
___________________________________________________________________
Reviewing Large Changes with Jujutsu
Author : bengesoff
Score : 93 points
Date : 2026-03-12 12:52 UTC (4 days ago)
(HTM) web link (ben.gesoff.uk)
(TXT) w3m dump (ben.gesoff.uk)
| tensegrist wrote:
| 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 wrote:
| 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.
| bananadonkey wrote:
| 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.
| pzmarzly wrote:
| 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 wrote:
| This would avoid dealing with merge conflicts when the PR
| changes, which is nice.
| cube2222 wrote:
| 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...
| 1718627440 wrote:
| 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
| steveklabnik wrote:
| > 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.
| abound wrote:
| 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
| sfink wrote:
| 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.)
___________________________________________________________________
(page generated 2026-03-16 23:01 UTC)