Focus on judiciously: mostly (functionally) atomic commits that are not every tiny change, not largely meaningless time-based snapshots, not Gerrit-style single commits for entire features, etc. I’m well aware of the mental leap you’re talking about, it’s neither hard to understand nor the liberation you might think it is. To achieve what we want to achieve we either need to be able to split, or “commit” with such atomicity that more time is wasted come squash time.* If you don’t get that, totally fine, but then you just don’t belong very much to this very conversation.
* Or we can completely change how we write code…
Small commits are the same small commits in jj as in git, you just split instead of add -p.
You can also stage or unstage lines by selecting them first and press the relevan keys.
If you press ‘return’ on a hunk, it brings you directly the the line to edit.
actually, with jj's seamless rebases, it'd work exactly as you'd want it to (but maybe not how you'd expect if you're used to the git way) when aimed at a commit in the middle of a branch: pick lines which stay below, above or in the middle commit, which you can edit transparently.
Interactive rebasing is a breeze. Editing commits is very fast (reordering, dropping rewording, splitting,…). Same with dealing with merge conflicts (Emacs have various merge packages builtin).
The same speed Vim brings to editing, that’s nearly the same speed you get with magit for git.