> For people like me who stage/commit often and judiciously

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…

I see your point, but this feels like a difference in workflow philosophy, especially with AI-assisted coding becoming more common.

With jj, your working copy is always a commit. This encourages a "commit often and messy, clean up later" approach. You can rapidly iterate with or without AI, letting jj automatically save every change without stopping to craft perfect atomic commits.

Later, you use a simple jj squash to combine all those small, iterative changes into logical, clean commits before you share it. The atomicity is created retroactively, not upfront. For a finely-tuned magit workflow this might feel wrong, but for rapid, exploratory and AI-driven iteration, it's a more natural fit.

With AI there’s even more reason to have ergonomic splitting if you care about quality commits, since unless you always write the perfect focused prompt, AI can over-generate for the scope of a single commit, so sooner or later you need to split that commit during the cleanup process you mentioned.

I’m using jj for almost a year now and I definitely feel much happier whenever I need to rebase a branch or do an octopus merge. It really is liberating in an incremental way that creeps on you in day to day work. Don’t expect a revolution, though.

Small commits are the same small commits in jj as in git, you just split instead of add -p.

I mean, if you think git add -p is fine then you’re clearly not in the market of magit. And yes, jj split is about as ergonomic as git add -p, IIRC.

What does the magit interface for staging look like? I only used GUIs were you select the lines with the cursor or mouse and stage that. Is it like that or more sophisticated? Does it support editing hunks better, because that's a thing I only do on the commandline, because my Git GUI doesn't support that.

In magit, the diff is splitted into sections: Untracked, Unstaged and Stage. The sublevels are files then hunks. You can stage and unstage hunks, files and whole section by pressing s and u. Pressing k discards the node (section, file, or hunk.

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.

jj wouldn't have any issues with supporting this workflow, if you could replace magit's git commands with some jj ones it'd probably just work. IOW the only thing that's missing is elbow grease.

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.

The thing is that magit have a lot of commands that makes rebasing a breeze. Pressing c, then s, will allow you to select interactively (from the commits log) a commit to target when doing autosquash. That will create a new commit with the relevant message. Pressing c, the S (shift+s), will rebase immediately, squashing the current staging area into the selected commit.

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.

It sounds like it’d would work even better with jj is all I’m saying. A rebase UI doesn’t mean a git rebase UI.

I don't mean that, I mean any tool that allows you to selectively stage can use the exact same interface to selectively split.

> Everything is a change and you bookmark a parent (or something further out) as the branch head into which you squash or advance the bookmark to a next ready change.

Does not sound any easier or more intuitive than git.

The only intuitive user interface is the nipple.

It isn’t how git porcelain wants you to work, but it does make sense once you stop thinking in git. Working copy being a first class commit unlocks all the dag manipulation tools without stashing, having to resolve conflicts in middle of tricky operations, etc. ‘Easier’ is exactly the point, but it’s about workflows which are very inconvenient in git like rebasing stacked PRs.