3 ms·

jj is actually so good though. People don't need to know you're using it, which is why it's nice. A problem I run into when working with other people is that

jj is actually so good though. People don't need to know you're using it, which is why it's nice. A problem I run into when working with other people is that code reviews take forever and I need to build on top of them. Code gets merged while it's being reviewed, and it becomes a burden to keep rebasing your stack of PRs. It's also difficult to do things like designing each PR against the main branch, but testing all 3 of them together. (Sometimes you want to write the docs / take screenshots as though all your features are merged as-is.) jj makes all this trivial. You tell it what you want and it does it without involving an index or working copy or interrupting you to resolve conflicts. I've found that it really makes me less annoyed when working with other people. I don't know why it takes people longer to review code (or to even open the review request) than it takes me to write things. But it does, and jj is what keeps me sane. To be fair, I also use it on personal projects because sometimes you have 3 things you want to try at once and they're not related to each other. Upstream isn't going to change without your understanding, but it's still mechanically something to maintain the rebases on those 3 branches. jj just makes this burden go away. Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git.

constantius 1y ago
I have a question and you might have an idea about this: I have a workflow where I have my main and a bunch of branches that are children of other branches. So: main, branch_a, branch_a_1, branch_a_2, branch_a_1_x, etc. Probably not a good workflow, but that's what I do. I keep editing old commits in my branches to have clean, atomic commits, which fucks up my branch structure and I need to cascade-rebase everything manually. Do I understand correctly that jj does it automatically?
- steveklabnik 1y ago
  That's correct, it will do the cascade rebase of everything automatically.
  - constantius 1y ago
    Thanks Steve, and for the tutorial too!
- 1718627440 1y ago
  git rebase --update-refs
  - martinvonz 1y ago
    That won't update sibling branches
    - 1718627440 1y ago
      It won't update (sibling) branches, that are checked out. --update-refs, --no-update-refs Automatically force-update any branches that point to commits that are being rebased. Any branches that are checked out in a worktree are not updated in this way. If the configuration variable rebase.updateRefs is set, then this option can be used to override and disable this setting.
  - Iwan-Zotow 1y ago
    Won't work, only tree
conradludgate 1y ago
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
- ricericerice 1y ago
  i believe `jj fix` is your -x equivalent, though im not familiar enough with it to comment on how similar the semantics actually are
  - conradludgate 1y ago
    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
    - martinvonz 1y ago
      > 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 https://github.com/jj-vcs/jj/issues/1869). It's just not done yet.
Vinnl 1y ago
> Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git. When you make a change to a pr in response to review feedback, do you just jj edit it in, and end up with a force push on GitHub? After which the review comment might get detached from the code or even hidden. That's definitely something that could be better for me. (That said, there are other projects making it better too.)
- jrockway 1y ago
  Yeah, I always force push. I always treat PRs as one atomic unit ("squash and merge") and the history that goes into the PR isn't relevant to me after it's merged. Maybe once or twice I've regretted this (maybe you want to backport one part of this PR to the release branch, and now you have to manually create that) but in general, how something is made can be ugly and it feels good to me to erase it when something is ready to be merged.
  - jjmarr 1y ago
    I'm banned from force-pushing at work so this makes jujutsu a challenge for me. The workflow still functions, it just requires me to manually update bookmarks.
    - jrockway 1y ago
      I see. I guess you guys keep merging in your upstream branch until it's finally time to merge a PR into that branch? A lot of people like that workflow but it never really made sense to me. I personally feel like your employer's policy is unusual for PR branches. Other people force pushing? Bad. Force-pushing to `main`? Bad. But force pushing to your own branch when you can delete it and re-create it? Just a waste of your time for no real reason. I wonder what the justification is.
      - jjmarr 1y ago
        > I see. I guess you guys keep merging in your upstream branch until it's finally time to merge a PR into that branch? A lot of people like that workflow but it never really made sense to me. Correct. It makes sense to me because it leaves a linear history of git commits in response to comments on a PR which makes code review easier. We squash and rebase at the end. > Just a waste of your time for no real reason. I wonder what the justification is. We used to be on Gerrit, which I found better for code review as I could stack a bunch of minute changes together. I probably had 50-100% more productivity on Gerrit before my team made the switch. Unfortunately, the industry standard is GitHub PRs. My team wasted a ton of time onboarding people to Gerrit and even after onboarding, less than 5% of people understood stacked changes enough to use them effectively. Since force pushing/rebasing messes up GitHub PRs it was banned. If you have suggestions for alternative code review workflows on GitHub I'm happy to hear them, but ideally they could be incremental.

constantius 1y ago

I have a question and you might have an idea about this: I have a workflow where I have my main and a bunch of branches that are children of other branches. So: main, branch_a, branch_a_1, branch_a_2, branch_a_1_x, etc. Probably not a good workflow, but that's what I do. I keep editing old commits in my branches to have clean, atomic commits, which fucks up my branch structure and I need to cascade-rebase everything manually. Do I understand correctly that jj does it automatically?

steveklabnik 1y ago
That's correct, it will do the cascade rebase of everything automatically.
- constantius 1y ago
  Thanks Steve, and for the tutorial too!
1718627440 1y ago
git rebase --update-refs
- martinvonz 1y ago
  That won't update sibling branches
  - 1718627440 1y ago
    It won't update (sibling) branches, that are checked out. --update-refs, --no-update-refs Automatically force-update any branches that point to commits that are being rebased. Any branches that are checked out in a worktree are not updated in this way. If the configuration variable rebase.updateRefs is set, then this option can be used to override and disable this setting.
- Iwan-Zotow 1y ago
  Won't work, only tree

conradludgate 1y ago

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

ricericerice 1y ago
i believe `jj fix` is your -x equivalent, though im not familiar enough with it to comment on how similar the semantics actually are
- conradludgate 1y ago
  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
  - martinvonz 1y ago
    > 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 https://github.com/jj-vcs/jj/issues/1869). It's just not done yet.

Vinnl 1y ago

> Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git. When you make a change to a pr in response to review feedback, do you just jj edit it in, and end up with a force push on GitHub? After which the review comment might get detached from the code or even hidden. That's definitely something that could be better for me. (That said, there are other projects making it better too.)

jrockway 1y ago
Yeah, I always force push. I always treat PRs as one atomic unit ("squash and merge") and the history that goes into the PR isn't relevant to me after it's merged. Maybe once or twice I've regretted this (maybe you want to backport one part of this PR to the release branch, and now you have to manually create that) but in general, how something is made can be ugly and it feels good to me to erase it when something is ready to be merged.
- jjmarr 1y ago
  I'm banned from force-pushing at work so this makes jujutsu a challenge for me. The workflow still functions, it just requires me to manually update bookmarks.
  - jrockway 1y ago
    I see. I guess you guys keep merging in your upstream branch until it's finally time to merge a PR into that branch? A lot of people like that workflow but it never really made sense to me. I personally feel like your employer's policy is unusual for PR branches. Other people force pushing? Bad. Force-pushing to `main`? Bad. But force pushing to your own branch when you can delete it and re-create it? Just a waste of your time for no real reason. I wonder what the justification is.
    - jjmarr 1y ago
      > I see. I guess you guys keep merging in your upstream branch until it's finally time to merge a PR into that branch? A lot of people like that workflow but it never really made sense to me. Correct. It makes sense to me because it leaves a linear history of git commits in response to comments on a PR which makes code review easier. We squash and rebase at the end. > Just a waste of your time for no real reason. I wonder what the justification is. We used to be on Gerrit, which I found better for code review as I could stack a bunch of minute changes together. I probably had 50-100% more productivity on Gerrit before my team made the switch. Unfortunately, the industry standard is GitHub PRs. My team wasted a ton of time onboarding people to Gerrit and even after onboarding, less than 5% of people understood stacked changes enough to use them effectively. Since force pushing/rebasing messes up GitHub PRs it was banned. If you have suggestions for alternative code review workflows on GitHub I'm happy to hear them, but ideally they could be incremental.