I consider git the best software ever written. I used to work with some other SVCs, and I cannot thinking on leaving git now. Somehow, I feel it like a limitation for my mind.
I'm following this Jujutsu project, I'm genuinely curious to see what it can bring to the SVC scene.
Having worked with cvs and svn, git has been an absolute blast.
That said, the first thing I do now in a repo is jj init --colocate. The fact alone that there is an operation log in jj, so you can easily revert your last command, or go back to any point you want, is mind blowing coming from git and having experienced frantically digging through the reflog.
But that aside, the way to work with branches ahem bookmarks, commits, conflicts, just makes so much sense in a world where simultaneous feature branches are a thing.
My journey was CVS->SVN->darcs->Hg->git. I can thoroughly recommend at least playing around with the others to see what you're missing. Darcs in particular I remember as having a much nicer model than either git or mercurial, but it had a horrible corner case behaviour. Pijul is supposed to fix that, but I haven't tried it yet.
That's interesting. I consider git the worst software ever written!
I speak specifically of the UI. Obviously the underlying system works. Yet it's totally within reason that the UI has wasted trillions of money and many person years in lost productivity.
Napkin math. It's easy to waste 30 minutes figuring out what the heck is going on after a command didn't work, or explaining what a detached head is to a newbie, or any number of completely avoidable issues were the UI better.
Consider the 26.9 million developers in North America[1]. How does one estimate the average salary across NA? Some in SV make 3x that. Elsewhere, it's conceivable that people make considerably less. Let's just say 100k. That's 100,000÷52÷40=48/hr or 24 per half hour. Anyone with git, I think it's safe to say, has had at least one stupid issue that took 30 minutes because of the UI. That's 26.9×24=645,600,000 monies.
In my experience and what I've seen of anyone who'a used git, 30 minutes is a gross underestimate. And people use git outside of NA. It's easily trillions in waste.
I'm glad they found a workflow that works for them, but
> but for some reason I cannot proceed on it while eg the CI is running, but I also don’t want to leave the commit and close my code editor etc. It would be simple to just stash everything and later pop the stash, but it still feels disruptive.
I have been using jj as my git client for 2 years now (wow), and I have never considered this to be disruptive. I just immediately switch to a new commit where I want to go, rather than making a new workspace to work in. Maybe it's a difference in the editor that I use (GNU Emacs) that makes this more natural?
if you don't do much in terms of accumulating open buffer/window sets, editor open at the specific line you were working on etc, then you'll feel it less.
or things like just keeping the terminal history consistent with a change if you look at things like compile command outputs etc.
In git you can have only one worktree per branch. For example, if you have a worktree on main you cannot have another one on main.
I personally find this annoying. I usually like to keep one pristine and always current working copy of main (and develop if applicable) around for search and other analysis tasks[1]. Worktrees would be ideal and efficient but due to the mentioned restriction I have to either waste space for a separate clone or do some ugly workarounds to keep the worktree on the branch while not keeping it on the branch.
jujutsu workspace are much nicer in that regard.
[1] I know there are tons of ways search and analyze in git but over the years I found a pristine working copy to be the most versatile solution.
Re Worktree/Spaces alternative: Why not just open up a new editor window ?
> I usually use it when I’ve got one task I’m working on, but for some reason I cannot proceed on it while eg the CI is running, but I also don’t want to leave the commit and close my code editor etc. It would be simple to just stash everything and later pop the stash, but it still feels disruptive.
What comeback? It’s been there for years and people who have use for them use them (or use git-clone(1) if they are not aware of them). It didn’t fall out of use at any point.
That there are a few programs that massage git worktree output and adds some navigation and “management” I can understand. That there are seemingly dozens and people publish new ones every month I can’t.
I want a variant of this where I make a worktree that has no ability to push anywhere including its parent. Instead the parent worktree pulls from it automatically. That way I can run some sandboxed workflow that might arbitrarily corrupt the work tree, possibly overwriting everything in it and symlinked from it, without losing data.
It's not really usable to me as the workspace folder doesn't have .git in it, even though original repo is collocated and hence the git tools don't work there.
I am forced to use git work trees with separate collocated JJ repo each.
I found worktrees unnecessarily painful in Git with little advantage over just having two copies of the repo.
Your far better off just having a clone of your primary repo, and have your primary repo as a local remote. Both can have a remote for GitHub and a separate remote for each other.
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.
As for worktree, jj or git, it has become the defacto way to work on multiple branches in paralell, using AI. Unlike the non AI workflow where you don't switch often, working with AI involves more branches that can be worked on in parallel and switching back and forth quite rapidly.
26 comments
[ 0.19 ms ] story [ 45.7 ms ] threadI'm following this Jujutsu project, I'm genuinely curious to see what it can bring to the SVC scene.
That said, the first thing I do now in a repo is jj init --colocate. The fact alone that there is an operation log in jj, so you can easily revert your last command, or go back to any point you want, is mind blowing coming from git and having experienced frantically digging through the reflog.
But that aside, the way to work with branches ahem bookmarks, commits, conflicts, just makes so much sense in a world where simultaneous feature branches are a thing.
I speak specifically of the UI. Obviously the underlying system works. Yet it's totally within reason that the UI has wasted trillions of money and many person years in lost productivity.
Napkin math. It's easy to waste 30 minutes figuring out what the heck is going on after a command didn't work, or explaining what a detached head is to a newbie, or any number of completely avoidable issues were the UI better.
Consider the 26.9 million developers in North America[1]. How does one estimate the average salary across NA? Some in SV make 3x that. Elsewhere, it's conceivable that people make considerably less. Let's just say 100k. That's 100,000÷52÷40=48/hr or 24 per half hour. Anyone with git, I think it's safe to say, has had at least one stupid issue that took 30 minutes because of the UI. That's 26.9×24=645,600,000 monies.
In my experience and what I've seen of anyone who'a used git, 30 minutes is a gross underestimate. And people use git outside of NA. It's easily trillions in waste.
https://en.wikipedia.org/wiki/Software_engineering_demograph...
You haven't used much software, I take it.
“de facto” please.
> but for some reason I cannot proceed on it while eg the CI is running, but I also don’t want to leave the commit and close my code editor etc. It would be simple to just stash everything and later pop the stash, but it still feels disruptive.
I have been using jj as my git client for 2 years now (wow), and I have never considered this to be disruptive. I just immediately switch to a new commit where I want to go, rather than making a new workspace to work in. Maybe it's a difference in the editor that I use (GNU Emacs) that makes this more natural?
or things like just keeping the terminal history consistent with a change if you look at things like compile command outputs etc.
I personally find this annoying. I usually like to keep one pristine and always current working copy of main (and develop if applicable) around for search and other analysis tasks[1]. Worktrees would be ideal and efficient but due to the mentioned restriction I have to either waste space for a separate clone or do some ugly workarounds to keep the worktree on the branch while not keeping it on the branch.
jujutsu workspace are much nicer in that regard.
[1] I know there are tons of ways search and analyze in git but over the years I found a pristine working copy to be the most versatile solution.
> I usually use it when I’ve got one task I’m working on, but for some reason I cannot proceed on it while eg the CI is running, but I also don’t want to leave the commit and close my code editor etc. It would be simple to just stash everything and later pop the stash, but it still feels disruptive.
I have a script that takes Github issues and spins them out into their own worktrees with corresponding stack.
I can then run individual instances of Claude Code in each and easily flip between them.
[0] https://haacked.com/archive/2025/11/21/tree-me/
Sorry, but I don't get the improvement.
Your far better off just having a clone of your primary repo, and have your primary repo as a local remote. Both can have a remote for GitHub and a separate remote for each other.
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.
As for worktree, jj or git, it has become the defacto way to work on multiple branches in paralell, using AI. Unlike the non AI workflow where you don't switch often, working with AI involves more branches that can be worked on in parallel and switching back and forth quite rapidly.