For anyone else that has absolutely no idea what this is: https://github.com/jj-vcs/jj
VisualJJ – Jujutsu in Visual Studio Code
61–70 of 90 posts
Re: VisualJJ – Jujutsu in Visual Studio Code
#62This 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.
Re: VisualJJ – Jujutsu in Visual Studio Code
#63Earlier quoted context omitted.
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.
Given jj's rebasing tooling, rewiring precommit into "prepush" feels like the right way forward. There's a bit of a phase transition between commits on your machine and commits that are out in the wild, after all.
Maybe! I agree that it feels kinda better. I’m not a huge hook user personally though.
Re: VisualJJ – Jujutsu in Visual Studio Code
#64Earlier quoted context omitted.
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.
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.
The OP is talking about the `jj workspace create` command, which creates a separate working copy backed by the same repository. It’s not a bad way to work with multiple agents, but you do have to learn what to do about workspace divergence.
Like git, you don’t lose any history.
Re: VisualJJ – Jujutsu in Visual Studio Code
#65Earlier quoted context omitted.
Git's plumbing is great. Git's porcelain is what sucks. JJ replaces the porcelain.
Git's plumbing also kinda sucks (in places). Some of the current limitations of jj in what syncing state between repos is due to things missing from git that they are having a hard working around, at least based on what I've seen browsing their tickets. That inability to push the really useful jj state upstream for pulling from any machine seems like a major pain point in jj right now (was one of the major issues ref…
This comment made me reconsider my attitude about git a little bit. Thank you.
Re: VisualJJ – Jujutsu in Visual Studio Code
#66I'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.
Re: VisualJJ – Jujutsu in Visual Studio Code
#67I 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…
Yeah, in an ideal world we'd have "save hooks" but that would probably be much too computationally expensive in some cases.
Re: VisualJJ – Jujutsu in Visual Studio Code
#68Earlier quoted context omitted.
For anyone that does not work at Google, it sounds like an implementation detail that does not matter.
Yes, at the moment it does not. But a well factored system is important for gaining future benefits. For example, I work at a startup that is building jj related tooling, and that the git stuff is separated out cleanly is what enables us to build better things than if it were so tied to git. To complete the analogy, given that we haven't launched, yes, this is a theoretical benefit for now. But that doesn't mean it's…
10 years of using Git and I never knew undo was what I craved. And the ability to rebase and edit commits in a single command.
Solves 90% of my problems so haven't felt like I needed any additional tooling on top of jj.
But I am curious is there some edge case on jj that I missed. That you folks are working on improving tooling for?
Just really curious about this new world with some better solutions to git.
I liked pijul a bunch too but lack of compat with git meant I can't use it for work... Haha real sad moment right there.
Re: VisualJJ – Jujutsu in Visual Studio Code
#69Earlier quoted context omitted.
Given jj's rebasing tooling, rewiring precommit into "prepush" feels like the right way forward. There's a bit of a phase transition between commits on your machine and commits that are out in the wild, after all.
Maybe! I agree that it feels kinda better. I’m not a huge hook user personally though.
For me it's mostly about doing as much of CI locally as feels reasonable to do quickly to save an iteration cycle. But I live in a world of badly configured text editors and the like so I usually have some silly formatting error
Re: VisualJJ – Jujutsu in Visual Studio Code
#70Earlier quoted context omitted.
Yes, at the moment it does not. But a well factored system is important for gaining future benefits. For example, I work at a startup that is building jj related tooling, and that the git stuff is separated out cleanly is what enables us to build better things than if it were so tied to git. To complete the analogy, given that we haven't launched, yes, this is a theoretical benefit for now. But that doesn't mean it's…
10 years of using Git and I never knew undo was what I craved. And the ability to rebase and edit commits in a single command. Solves 90% of my problems so haven't felt like I needed any additional tooling on top of jj. But I am curious is there some edge case on jj that I missed. That you folks are working on improving tooling for? Just really curious about this new world with some better solutions to git. I liked p…
Not working on it (yet), but I wish the jj github story was a little more ergonomic.
Additionally, I am really missing support for stacked diffs, ie, easily pushing a number of commits into one PR on github each such that they all show their incremental diff.
ezyang's gh stack was pretty useful, if a little bit fragile [0] and graphite.dev is also very nice, but paid software with a strong VC based motivation to become everyone's everything instead of a nice focused tool.
[0] https://github.com/ezyang/ghstack
I'm also not super happy with the default 3-way merge editor, but often cannot use vscode or other GUIs.