I See a Future in Jj

Re:I See a Future in Jj by conradludgate on Wednesday October 22, 2025 @05:25PM (#45675362)

I use git but I instead just keep all PRs stacked on top of each other and rebase when one is merged. If something is easy to review I push it down the stack. If something is harder to review I keep it at the top of the stack.

I don't open a PR for each commit, and we use squash commits at work which makes it harder to have this workflow but it still works fine for me.

I rebase only the leaf PR, and I have update-ref enabled to update the branch refs of all other branches in the stack. It works well. The only manual process is that I have to manually force push each branch afterwards.

Lastly, I use the `-x "cargo fmt" -x "cargo clippy"` feature when rebasing (which is missing in jj) to make sure the stack stays in a good state

[ Parent | on HN ]

Re:I See a Future in Jj by ricericerice on Wednesday October 22, 2025 @11:57PM (#45678033)

i believe `jj fix` is your -x equivalent, though im not familiar enough with it to comment on how similar the semantics actually are

[ Parent | on HN ]

Re:I See a Future in Jj by conradludgate on Thursday October 23, 2025 @01:55AM (#45678600)

It is not even close to sufficient. jj fix only executes the command on one file at a time (only the changed files) so it can't work on anything that has linter semantics.

jj does this for performance reasons. They don't want to perform a full checkout for every rebase action. This is simply something I disagree with

[ Parent | on HN ]

Re:I See a Future in Jj by martinvonz on Thursday October 23, 2025 @02:14AM (#45678739)

> jj does this for performance reasons. They don't want to perform a full checkout for every rebase action.

It's true that `jj fix` can be faster by not touching the working copy, but we also want a `jj run` command for the linter feature (https://github.com/jj-vcs/jj/issues/1869). It's just not done yet.

[ Parent | on HN ]