I see a future in jj

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.

Oh wow, they were going for "magic" with that name?? I read it as "maggot".

I’m curious what the magit hunk selection UX consists in. I couldn’t find any videos showing something substantially different from the one built into jj — the videos I found were meant as beginner intros.

I’ve never used magit but I used GitUp (https://gitup.co/) for years before jj. I don’t find the jj one super natural, but I feel like that’s mostly a matter of keyboard shortcuts — I need to see if they can be customized.

There's more than one way to do it, but the very normal UX is that you can just scroll through the diff file-by-file and stage/stash/drop each hunk individually by placing your cursor over it and issuing the appropriate command. You can do the same with files, staging/stashing/dropping changes to a file by placing the cursor on its name and issuing a command.

Seriously! I found that you can still use the git index as long as you don’t run any jj command that changes git_head, and then I made an alias to make a commit from staged changes (squash-index and split-index): https://github.com/CGamesPlay/dotfiles/blob/2484f6f7d0ab302e...

Crucially you can also select a region within a chunk and perform those commands, so it’s easy to untangle changes.

If you open your favorite git editor in a jj repo, everything you stage will become a new commit, everything you revert will… revert. I still use Sublime Merge rather frequently.

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.

> 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…

If you understand why having a great UX on top of bare git is valuable, you have understood 95% of what's to understand about jj.

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.

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.

And you can even edit the content you stage, so that you can stage something different, than what is in the working tree. Having different content in the index vs. working tree is the feature of the index, which I think JJ just doesn't support?