It does look nice, I'll give it a go. Just wanted to say that "Git-out-of-the-way source control" is the best tiny description of JJ I've ever seen, because it's both true and the pun works perfectly. It brought me joy.
I worked with JJ for half a year, and it was great. However, I've since decided to go back to GIT because of compatibility with existing workflows and AI tools.
Pre-commit hooks are not possible [yet?], which is a minor inconvenience. Worse, workspaces/worktrees use a different mechanism. This causes like Claude Desktop (which uses worktrees) to break. Also Claude and other agents are always confused about JJ and fall back to git too often.
Seeing similar comments across different articles and technologies and it makes me wonder how much AI is going to hold back the adoption of new technologies going forward.
I agree it will hold back new technologies, but, at the same time, I'm not sure what the value add of new technologies will be going forward. Often, as is the case with git vs. jj, the value add of a new technology is mostly ergonomic. As AI becomes more ingrained in the development flow, engineers won't engage with the underlying tech directly, and so ergonomic benefits will be diminished. New technologies that emerge will need to provide benefits to AI-agents, not to engineers. Should such a technology emerge, agent developers will likely adopt it.
For this reason, programming languages, at least how we understand them today, have reached a terminal state. I could easily make a new language now, especially with the help of Claude Code et al, but there would never be any reason for any other engineer to use it.
My team is asking the same. We are using jj with great success but tools like auto claude are designed around git and git worktrees. It's a shame - at least with git backend we can sort of make things work together.
There's a different, open source Jujutsu extension as well: https://github.com/keanemind/jjk
It does look nice, I'll give it a go. Just wanted to say that "Git-out-of-the-way source control" is the best tiny description of JJ I've ever seen, because it's both true and the pun works perfectly. It brought me joy.
it is worth noting that Jujutsu uses Git’s storage, networking, and ecosystem.
I worked with JJ for half a year, and it was great. However, I've since decided to go back to GIT because of compatibility with existing workflows and AI tools.
Pre-commit hooks are not possible [yet?], which is a minor inconvenience. Worse, workspaces/worktrees use a different mechanism. This causes like Claude Desktop (which uses worktrees) to break. Also Claude and other agents are always confused about JJ and fall back to git too often.
Seeing similar comments across different articles and technologies and it makes me wonder how much AI is going to hold back the adoption of new technologies going forward.
I agree it will hold back new technologies, but, at the same time, I'm not sure what the value add of new technologies will be going forward. Often, as is the case with git vs. jj, the value add of a new technology is mostly ergonomic. As AI becomes more ingrained in the development flow, engineers won't engage with the underlying tech directly, and so ergonomic benefits will be diminished. New technologies that emerge will need to provide benefits to AI-agents, not to engineers. Should such a technology emerge, agent developers will likely adopt it.
For this reason, programming languages, at least how we understand them today, have reached a terminal state. I could easily make a new language now, especially with the help of Claude Code et al, but there would never be any reason for any other engineer to use it.
Innovation budget is a finite resource
My team is asking the same. We are using jj with great success but tools like auto claude are designed around git and git worktrees. It's a shame - at least with git backend we can sort of make things work together.
There is no reason to use a VS Code extension, jjui is amazing! https://github.com/idursun/jjui
I wanted the same extension but more steerable and open source, so I built open jj recently https://github.com/olup/open-jj
You gotta put screenshots in the readme!
Not to be confused with Visual J++ :)
Just me or does sit well to monetize _mostly_ off the core benefits of an open source application?
Can't be easy to build a GUI on top, but I'm sure a 10% revenue to be redistributed to the hero behind jj would go a long way. Would also pay off.
There is nothing about neither the licensing of jj or the spirit of open source that stigmatizes this.
The hero behind jj is employed by Google afaik, so we're good.
10% revenue to google?