←back to thread

I see a future in jj

(steveklabnik.com)
343 points steveklabnik | 5 comments | 22 Oct 25 17:21 UTC | HN request time: 0s | source
Show context
oefrha ◴[23 Oct 25 01:16 UTC] No.45677124[source]▶
I gave jj two honest tries. While first class conflicts is a cool idea, in practice I deal with staging/committing 30x more than conflict resolution, and coming from magit, using jj’s hunk split & select felt like being thrown into stone age. Plus I rebase a lot and get a lot of jj’s benefits from magit’s various rebase shortcuts already, IIRC first class conflicts was the only truly novel thing I didn’t have. For people like me who stage/commit often and judiciously I don’t think jj will beat magit until its hunk selection UX comes close.
replies(7): >>45677310 #>>45677775 #>>45678027 #>>45678524 #>>45678766 #>>45679013 #>>45683613 #
baq ◴[23 Oct 25 06:19 UTC] No.45678766[source]▶
In jj you aren’t supposed to be even thinking about staging and committing, that’s the mental leap required to get what the fuss is about. 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.
replies(2): >>45678857 #>>45680611 #
oefrha ◴[23 Oct 25 06:38 UTC] No.45678857[source]▶
> 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…

replies(2): >>45679025 #>>45679168 #
baq ◴[23 Oct 25 07:27 UTC] No.45679168[source]▶
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.

replies(1): >>45679713 #
oefrha ◴[23 Oct 25 08:52 UTC] No.45679713[source]▶
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.
replies(2): >>45679991 #>>45680423 #
1. 1718627440 ◴[23 Oct 25 10:56 UTC] No.45680423[source]▶
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.
replies(1): >>45680648 #
2. skydhash ◴[23 Oct 25 11:32 UTC] No.45680648[source]▶
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.

replies(1): >>45680752 #
3. baq ◴[23 Oct 25 11:47 UTC] No.45680752[source]▶
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.

replies(1): >>45682518 #
4. skydhash ◴[23 Oct 25 14:52 UTC] No.45682518{3}[source]▶
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.

replies(1): >>45682919 #
5. baq ◴[23 Oct 25 15:23 UTC] No.45682919{4}[source]▶
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.