V
Story
VisualJJ – Jujutsu in Visual Studio Code
  • lima
  • ·
  • 6 hours ago
  • ·
  • [ - ]
There's a different, open source Jujutsu extension as well: https://github.com/keanemind/jjk
jjk caused a lot of problems for me when using multiple agents. It's running some sort of jj command that snap-shotted stuff and caused divergence (might have benefited from `--ignore-working-copy`). Not sure what the precise details were, but I gave up and uninstalled it after a week.
  • Okkef
  • ·
  • 5 hours ago
  • ·
  • [ - ]
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.

  • Yeroc
  • ·
  • 5 hours ago
  • ·
  • [ - ]
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.
  • j1elo
  • ·
  • 1 hour ago
  • ·
  • [ - ]
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.

How does your AI agent deal with large merge conflict resolution?
Even breaking changes in a library can cause massive pain. AI constantly wants to the use the old pattern it was trained on. Up until a few months ago it would always prefer using the 2021 edition of rust rather than 2024 for instance. Overall though I don't think this is insurmountable, but it definitely adds an impediment which will overall motivate people to do things non optimally for the foreseeable future. Luckily, not everyone is bound by AI today. I just write my own commits messages instead of letting the AI do it. jj is popular enough that I'm sure it'll learn how to use it in the next year (especially Gemini because Google is using jj internally and would probably train it on it as a result)
Claude Code has zero issue using jj, for what it’s worth.
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.

Even if you're not authoring changes as much, change management is likely still to be a very useful activity for a long while. Also note that not everyone is using AI today, and many that do only use it as glorified auto complete. It will take many more years for it's adoption to put us in a situation like your describing, why halt progress in the meantime? My personal productivity increased greatly by switching to jj, perhaps more than adding Gemini CLI to my workflow. I can more confidently work on several changes in parallel while waiting on things like code review. This was possible before but rebasing it and dealing with merge conflicts tended to limit me from doing it beyond a handful of commits. Now I can have 20+ outstanding commits (largely with no interdependencies) and not feel like I'm paying much management overhead while doing so. I can also get them reviewed in parallel more easily.
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.
Innovation budget is a finite resource
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 Claude decide what to do.

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
  • olup
  • ·
  • 5 hours ago
  • ·
  • [ - ]
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.
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.
  • Okkef
  • ·
  • 1 hour ago
  • ·
  • [ - ]
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
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.
It uses it when you use the git backend, but not when you don’t.

Right now, the only other backend is at Google, so it’s not practical for most people. But it’s not an inherent part of jj, and that’s really important, actually.

Git's plumbing is great. Git's porcelain is what sucks. JJ replaces the porcelain.
  • olup
  • ·
  • 5 hours ago
  • ·
  • [ - ]
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!
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?
  • nchmy
  • ·
  • 1 hour ago
  • ·
  • [ - ]
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.
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.
If anyone uses frontends like magit - what is the usecase for this?

I feel like git is just easy-mode with magit and I don't really miss a whole lot more. I totally get this is you are using the git cli or some such.

Might just be my limited imagination though of course.

One obvious case where magit isn’t useful as opposed to jj is if you’re not an emacs user.

jj has some additional features over just a nicer UI that I believe magit can’t do, but given that I haven’t used magit yet I am not 100% sure of how that comparison is exactly.

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.
Nothing against, I agree.
The hero behind jj is employed by Google afaik, so we're good.
10% revenue to google?
While the primary maintainer is a Google employee, the majority of commits and committers are not. It's decidedly not a Google project.
Touché
  • zerr
  • ·
  • 4 hours ago
  • ·
  • [ - ]
Not to be confused with Visual J++ :)
"Now, that's a name I've not heard in a long time. A long time."