Live data from Hacker News

VisualJJ – Jujutsu in Visual Studio Code

visualjj.com

31–40 of 90 posts

Re: VisualJJ – Jujutsu in Visual Studio Code

#31
post #10

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

Pre commit hooks are complicated because jj just has a fundamentally different lifecycle than git does. Tools that integrate with git specifically can be tough though, yeah. Some do Just Work, and some very much do not. I’ve found a “we use jj not git for this project” in Claude.md makes falling back to git rare, but I also tend to incorporate version control into slash commands or skills directly rather than let Cla…

I also prefer to manage version management myself directly, even with llm-gen'd CICD elements, so preferring jj hasn't been nearly as costly for me specifically :D

Re: VisualJJ – Jujutsu in Visual Studio Code

#33
post #12
post #10

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

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.

Claude Code has zero issue using jj, for what it’s worth.

Re: VisualJJ – Jujutsu in Visual Studio Code

#34

There is no reason to use a VS Code extension, jjui is amazing! https://github.com/idursun/jjui

I love jjui, but I feel like it's also the reason I still use him over vscode. If you already use vscode, doesn't using a vscode extension make more sense?

Of course there are some people that will want a gui not matter what. Then an extension or separate program is the only thing you can do. But i think it is really nice to have the same tool available everywhere, also in the terminal. And if you want a neat and vertical pane in vscode just drag a new terminal window next to your code and run jjui in it.

Re: VisualJJ – Jujutsu in Visual Studio Code

#35

There is no reason to use a VS Code extension, jjui is amazing! https://github.com/idursun/jjui

I love jjui, but I feel like it's also the reason I still use him over vscode. If you already use vscode, doesn't using a vscode extension make more sense?

If there was a vscode extension that had half the power of jjui, I'd consider it. But that's not the case. jjui is just amazing.

Re: VisualJJ – Jujutsu in Visual Studio Code

#36
post #30
post #10

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

I agree about hooks and workspaces, but I'm surprised your Claude is having issues with jj itself. jj is definitely in the training data now, so it might be a matter of guiding it with CLAUDE.md.

It usually works, but sometimes it'll try to use git instead of jj at random and needs a reminder. As JJ is not completely stable it tries some old commandline versions as well. This improved after I put in some lines in my agents file, but still it's much better at complex changes with git than jj.

Re: VisualJJ – Jujutsu in Visual Studio Code

#37
post #12
post #10

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

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 find it a bit ridiculous to see that people or whole teams don't want to use JJ (or any tool, for that matter) because in essence they hired a "support intern" (read: AI assistant) who doesn't know or want to use it.

Re: VisualJJ – Jujutsu in Visual Studio Code

#38
post #37
post #12

Earlier quoted context omitted.

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 find it a bit ridiculous to see that people or whole teams don't want to use JJ (or any tool, for that matter) because in essence they hired a "support intern" (read: AI assistant) who doesn't know or want to use it.

Why would I learn the abstraction of JJ on top of git when I've got a butler who's happy to deal with git directly?

You're right in principle, but it just seems JJ is a solution in search of a problem.

Re: VisualJJ – Jujutsu in Visual Studio Code

#39
post #14
post #12

Earlier quoted context omitted.

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

Ah yes, the inevitable future where the only way we'll know to interact with the machine is through persuading a capricious LLM. We'll spend our days reciting litanies to the machine spirits like in 40k.

Re: VisualJJ – Jujutsu in Visual Studio Code

#40
post #36
post #30

Earlier quoted context omitted.

I agree about hooks and workspaces, but I'm surprised your Claude is having issues with jj itself. jj is definitely in the training data now, so it might be a matter of guiding it with CLAUDE.md.

It usually works, but sometimes it'll try to use git instead of jj at random and needs a reminder. As JJ is not completely stable it tries some old commandline versions as well. This improved after I put in some lines in my agents file, but still it's much better at complex changes with git than jj.

If it helps, this was all I needed in my CLAUDE.md to make it use jj perfectly:

  # Version Control

  - IMPORTANT: YOU MUST assume we use Jujutsu ("jj") for version control. Check by running `jj root` (or look for a  `.jj/` directory) to confirm.
  - If I say "commit", "branch", "squash", etc., assume jj equivalents first. 
  - You can ignore any `git add` command, since jj always auto-adds.
  - Use `jj` commands instead of `git`. Never run `git` in a jj repository.
  - ALWAYS prefer jj change IDs over commit SHAs. jj change IDs are stable.
  - jj doesn't usually require named branches
  - If you need named branches, use `jj bookmark`, but you must manually update the bookmark after making new commits, since they won't automatically get updated
  - When reading data from jj, always use `--ignore-working-copy` to avoid snapshotting the working copy (which is slow and unnecessary for read operations). But when writing (commit, squash, rebase, etc.), you MUST NOT use `--ignore-working-copy`.
  - If you get "Error: The working copy is stale", run `jj workspace update-stale` first
Post reply on HN