VisualJJ – Jujutsu in Visual Studio Code

https://www.visualjj.com/

by demail • 6 months ago

181 89 6 months ago

viraptor• 6 months ago

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.

AbuAssar• 6 months ago

it is worth noting that Jujutsu uses Git’s storage, networking, and ecosystem.

SAI_Peregrinus• 6 months ago

Git's plumbing is great. Git's porcelain is what sucks. JJ replaces the porcelain.

steveklabnik7• 6 months ago

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.

lima• 6 months ago

There's a different, open source Jujutsu extension as well: https://github.com/keanemind/jjk

KingMob6• 6 months ago

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.

dwattttt2• 6 months ago

Multiple agents is definitely tempting fate. Concurrent modification of the same git repo by multiple entities?

At that point you should use multiple repos so they can merge & resolve.

EDIT: of course, if a single agent uses git to modify a repo instead of jj, jj may have trouble understanding what's happened. You could compare it to using an app that uses an sqlite db, and then also editing that db by hand.

hirako20003• 6 months ago

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.

throwatdem12311• 6 months ago

There is nothing about neither the licensing of jj or the spirit of open source that stigmatizes this.

hirako20003• 6 months ago

Nothing against, I agree.

Valodim• 6 months ago

The hero behind jj is employed by Google afaik, so we're good.

misnome• 6 months ago

10% revenue to google?

hirako20003• 6 months ago

Touché

surajrmal6• 6 months ago

While the primary maintainer is a Google employee, the majority of commits and committers are not. It's decidedly not a Google project.

olup2• 6 months ago

I wanted the same extension but more steerable and open source, so I built open jj recently https://github.com/olup/open-jj

IshKebab• 6 months ago

You gotta put screenshots in the readme!

Okkef2• 6 months 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• 6 months 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.

hippo222• 6 months ago

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.

ithkuil• 6 months ago

Innovation budget is a finite resource

surajrmal6• 6 months ago

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)

stouset• 6 months ago

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

j1elo• 6 months 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.

olup2• 6 months 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.

steveklabnik7• 6 months ago

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.

rtaylorgarlock• 6 months ago

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

zamalek• 6 months ago

Yeah, in an ideal world we'd have "save hooks" but that would probably be much too computationally expensive in some cases.

KingMob6• 6 months ago

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.

Okkef2• 6 months 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.

dwattttt2• 6 months ago

I wonder if you could replace the git commands exposed to an agent.

A 'commit' 'happens' when you leave a change in jj, i.e. by moving to a new or existing change; that's when you'd run pre-commit hooks.

steveklabnik7• 6 months ago

The problem with this is that at the limit, this means "run the precommit on every save of a file," which is not really usually how people think of precommit hooks.

SkoogyDan2• 6 months ago

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

surajrmal6• 6 months ago

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?

SkoogyDan2• 6 months ago

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.

nchmy3• 6 months 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.

quleap• 6 months ago

`jjui` is the best VCS TUI I've ever used, period. I tried `lazygit` and `magit` before and was not impressed.

nchmy3• 6 months ago

Strongly agree, and it's always getting better. The maintainer is a hero, and there's a few other regular contributors who do great work. They're always super responsive to feedback

zerr2• 6 months ago

Not to be confused with Visual J++ :)

KingMob6• 6 months ago

"Now, that's a name I've not heard in a long time. A long time."

zerr2• 6 months ago

Yeah, all of the kids moved to Visual J# :)

egeozcan• 6 months ago

At least that's somewhat relevant. Every time I hear JJ, I remember Jay-Jay Okocha: https://en.wikipedia.org/wiki/Jay-Jay_Okocha

bergheim• 6 months ago

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.

steveklabnik7• 6 months ago

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.

rtpg3• 6 months ago

rebasing, rebasing, rebasing.

I used/use magit a lot, and rebasing is much nicer with magit. But you're still faced with having to be in git land. JJ there's a lot of "rebasing at the speed of thought" because you really are just moving nodes around and "do what I mean" kicks in.

There's this other thing too, which is that jj I've always felt comfortable modifying changes that are not what I currently have checked out. With git it's always felt like the first step for any change management is "check out the changes into the working copy".

codethief• 6 months ago

Stay in your editor while GitHub does the rest. VisualJJ tracks pull-request status on the change tree and lets you create PRs in a couple of clicks, so moving changes from “draft” to “merged on GitHub” feels like one smooth flow.

Does it support stacking PRs?

EDIT: I should have looked more closely, looks like it does, though only in the Pro version: https://www.visualjj.com/docs/stacking

meling• 6 months ago

Great to see this. I played around with jj about two months ago and really enjoyed using it on the command line, but I found it difficult to understand the interaction with git and GitHub and decided to put it off until I had more time. (I don’t recall the specific issues I had…) Maybe this extension can remove some of that friction.

nailer• 6 months ago

For anyone else that has absolutely no idea what this is: https://github.com/jj-vcs/jj

gcr3• 6 months ago

This extension snapshots the working state every 60 seconds by default. I ran out of disk space and had to turn that behavior off. YMMV.

It’s a great extension otherwise though.

spartanatreyu• 6 months ago

I'm not convinced by jujutsu yet.

If I'm using git for version control, I'm going to use the Fork client (fork.dev) since it essentially replaces git's UI already.

And in a few years if I'm in the position where we want to switch away from git, I'd probably be looking at pijul.

But maybe that will change if jujutsu gets an open source non-git-based backend.

vivzkestrel• 6 months ago

stupid question: why do people want to move away from git? and why is this vcs being talked about a lot these days?

nchmy3• 6 months ago

Because jj is vastly simpler and more powerful than git, while being compatible with git (so you can keep using Github etc). There's tons of articles and videos on the topic, and many other posts here on HN about it

Check out jjui in particular. Makes it even easier

direwolf20• 6 months ago

git has a terrible user experience, but you use it because everyone else is and it's powerful — much like Linux

it would be good if there was a powerful VCS with a good user experience and git compatibility

surajrmal6• 6 months ago

Git makes certain workflows more difficult than they could be. Using a different tool that makes you feel more productive is generally nice.

sankar_builds• 6 months ago

cool.

vrnvu• 6 months ago

Ditched git for jj a year ago. Never going back.

If anybody is hesitant give it a try!

antman• 6 months ago

10$ per month early access? I would prefer a one off price for an offline mode

tester89• 6 months ago

Doesn’t seem to properly support workspaces :’(

VisualJJ – Jujutsu in Visual Studio Code

Related Stories