How does it just auto-rebase everything without failing though? If you edit something later commits depend on, then you get merge conflicts. Are you implying that jj just automatically handles all this?
I see. It doesn't deal with the conflict, it just proceeds regardless. I'm curious about how it works internally. Does it do something like commit the conflict and soft reset later?
The conflict markers are a first-class citizen in the repo. jj tells you when a commit has a conflict, and you can go edit it at your leisure. It also does prevent you from doing some things with branches in a conflicted state, like pushing them.
You might not think this is that big a deal, but this also means you don’t have to resolve the entire thing in one go. Plenty of times with complicated rebases in git, I’ve not been 100% certain about the path towards resolving it. But jumping around to view various commits when you’re in the rebase-conflict state is painful. In jj you can just switch to an earlier commit, tweak it there, jump to a later commit, see how it looks, etc. It removes 98% of the pain.
It also dovetails nicely with other aspects of jj. Since rebases happen automatically and constantly, they are usually tiny. If there’s a conflict, it’s caught right when you do the thing and not four hours later when that part is no longer fresh in mind. And the op log lets you restore and undo actions atomically, which makes undoing a fuck-up a no-op.
I've come to the opinion that conflicts should be committed and merge fixes should be in another commit afterwards. Arguably even if the merge fix is trivial.
A merge conflict means that some automated tool couldn’t figure it out. But all a merge is is a commit with two parents and an accompanying diff that shows the process of combining them. A merge conflict isn’t really in any way special. It just means whatever algorithm was used couldn’t do it unambiguously without human help.