Most active commenters
  • baq(4)
  • oefrha(4)

←back to thread

I see a future in jj

(steveklabnik.com)
325 points steveklabnik | 11 comments | 22 Oct 25 17:21 UTC | HN request time: 0.508s | source | bottom
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(6): >>45677310 #>>45677775 #>>45678027 #>>45678524 #>>45678766 #>>45679013 #
1. 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 #
2. 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 #
3. xintron ◴[23 Oct 25 07:02 UTC] No.45679025[source]▶
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.

replies(1): >>45679701 #
4. 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 #
5. oefrha ◴[23 Oct 25 08:50 UTC] No.45679701{3}[source]▶
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.
6. oefrha ◴[23 Oct 25 08:52 UTC] No.45679713{3}[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 #
7. baq ◴[23 Oct 25 09:39 UTC] No.45679991{4}[source]▶
I don't mean that, I mean any tool that allows you to selectively stage can use the exact same interface to selectively split.
8. 1718627440 ◴[23 Oct 25 10:56 UTC] No.45680423{4}[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 #
9. Hendrikto ◴[23 Oct 25 11:24 UTC] No.45680611[source]▶
> 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.

10. skydhash ◴[23 Oct 25 11:32 UTC] No.45680648{5}[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 #
11. baq ◴[23 Oct 25 11:47 UTC] No.45680752{6}[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.