Yes, I am familiar with git rebase. I can virtually assure you that everyone here evangelizing jj is aware of it too. Most of us were git power users. Steve Kla

Yes, I am familiar with git rebase. I can virtually assure you that everyone here evangelizing jj is aware of it too. Most of us were git power users. Steve Klabnik certainly was. I was too. Actually using git rebase is a pain in the ass when things don't go according to plan. Long chains of rebase conflicts suck. Making a mistake during a rebase sucks. Stashing sucks when you forget what branch the changes were on. Stashing also sucks when you have stash apply conflicts. None of this is ever a problem in jj due to the fundamental design. And you get some additional superpowers too. Today I was working on a feature that needs to be merged and deployed one piece at a time. There are (right now) four separate pieces, each comprising multiple commits. In jj it's just one linear chain of commits on top of `main` with four branch names assigned to the relevant interim commits. Each of those branches has an associated PR. When I need to make a change to something in one of the commits early in the chain, I just do it. If I need to make a new commit somewhere else in the middle, I just do it. It takes zero effort, and all later commits are automatically kept up to date with changes earlier in the tree. When I push, all the PRs are updated. When I end up merging the first of those four stages, there is zero work necessary to fix up the later three branches. Try doing that with git.