Never used jj, but isn't that just `git commit --amend`? Lets you add/remove/change changes from the previous commit by basically overwritting it with a new changeset+message.
I’m selling it short a bit - it does a lot more! There’s a great Steve Klabnik tutorial [1]. To me the main thing is it makes it very easy to think and work in terms of logical changes.
So does `git rebase -i $commit^1` and marking the commit with `edit`, any commit afterwards (which I think you mean by "downstream"?) also gets rewritten since you've changed a commit in the middle.
I'm not sure if you're selling it a bit short, or if `jj` just have a target audience that I am not a part of, both are of course ok :)
A lot of jj users are former Git power users. If all you do you use is `git clone`, `git commit -A`, `git push`, `git pull`, then there's much less to gain for you from switching.
Since you seem to know how to use interactive rebase, I think you are the target audience.
To clarify what's easier in the scenario mentioned above:
1. You don't need to check out a specific branch to start the interactive rebase from. You simply check out the commit you want to edit and then squash into.
2. You don't have to manually rebase other descendant branches. (I.e. if the commit you're modifying is in multiple branches.)
3. Branches (jj calls them bookmarks) get automatically updated. I know Git now has `--update-refs`, but you never need pass that with jj (maybe Git has a config for it, I haven't checked).
4. If you had a dirty working copy before you decided to fix up this commit, you won't need to manually stash or commit those changes.
5. If editing the commit results in conflicts in some descendant, you don't have to resolve those right away.
Try it and let us know how it goes?
Another example is `jj rebase -d main`. It may look very similar to `git rebase main`, but it rebases a whole tree. See https://stackoverflow.com/questions/17315285/rebasing-a-tree... if you don't know what I mean.
Another example is `jj squash --from main..my-branch --into my-other-branch some/path`, which removes all the changes to `some/path` that happen in any commits in `main..my-branch` and squashes them into the tip commit of `my-other-branch`.
Does that help? I'm not sure I understood your comment correctly.