Live data from Hacker News

Reviewing Large Changes with Jujutsu

ben.gesoff.uk

11–17 of 17 posts

Re: Reviewing Large Changes with Jujutsu

#11

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…

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.

Re: Reviewing Large Changes with Jujutsu

#12
post #9

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…

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 have been working on a 100% vibe-coded magit-style jujitsu porcelain for neovim. I cannot emphasize "vibe-coded" enough -- I have not read a single line of code here, nor do I know much about neovim development in general. All that said, it's been working pretty well for me the last couple weeks!

https://github.com/micahbf/maju.nvim

Re: Reviewing Large Changes with Jujutsu

#13
post #7

I use Jujutsu in mostly the same way at work. I have a `jj review ` 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

Thanks for telling me about prr, I've always wanted something like this!

Re: Reviewing Large Changes with Jujutsu

#14
post #9

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…

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 have been using https://github.com/idursun/jjui a lot and it has been great. Not sure how it compares to magit though.

Re: Reviewing Large Changes with Jujutsu

#15
post #14
post #9

Earlier quoted context omitted.

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 have been using https://github.com/idursun/jjui a lot and it has been great. Not sure how it compares to magit though.

I’ve been using it too, definitely recommend!

Re: Reviewing Large Changes with Jujutsu

#16
post #3

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.

This is very nice, I just tried it, thanks for the suggestion. I was messing around with rebasing subsequent PR updates onto the review commit but it got a bit messy with conflicts. The `jj restore` should solve it

Re: Reviewing Large Changes with Jujutsu

#17
post #8

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 noth…

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.
Post reply on HN