←back to thread

128 points nvader | 1 comments | | HN request time: 0.201s | source
Show context
fusslo ◴[] No.46192929[source]
I don't understand the workflow that makes JJ more useful than git. I dont think I've even had the idea of having multiple worktrees going at once. What is the use case? The author mentions being blocked by CI flow. Don't you have CI running on gitlab or github? just commit and push the branch and run CI. The author mentions stashing the changes, but like.. if you're running against CI, isn't it in a state that is commitworthy? I don't see how creating a worktree in a new folder and opening a new editor is more convenient than creating a branch at a certain commit.

I can understand if you need to run a CI or unit tests locally. Is that it?

I am not attacking JJ, I genuinely can't understand its value in my current workflow.

replies(9): >>46193047 #>>46193118 #>>46194204 #>>46194494 #>>46194612 #>>46194856 #>>46195079 #>>46200711 #>>46202517 #
SatvikBeri ◴[] No.46193118[source]
"When is jj useful" is a different question from "when are workspaces/git worktrees useful"

I find jj overall most useful for separating the concept of a machine-level commit history that saves every change from a human-readable commit history . jj has really nice tools for cleaning up your commits for review while still retaining all the mechanical changes in case you need to get more granular. (Of course, there are many other tools to do this, like magit – I just find jj to work best with my brain.)

Workspaces/worktrees are best when you have long-running tasks where the state of the disk is important. Local "CI" is a good example – kick off a long test run on one workspace while starting a new task in another. Another example these days is stuff with Agentic LLMs, e.g. I might create one workspace and ask Claude Code to do a deep investigation of why our AWS costs went up.

replies(1): >>46193604 #
1. ◴[] No.46193604[source]