Doesn’t seem to properly support workspaces :’(
VisualJJ – Jujutsu in Visual Studio Code
81–90 of 90 posts
Re: VisualJJ – Jujutsu in Visual Studio Code
#82stupid question: why do people want to move away from git? and why is this vcs being talked about a lot these days?
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
Re: VisualJJ – Jujutsu in Visual Studio Code
#83stupid question: why do people want to move away from git? and why is this vcs being talked about a lot these days?
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
Re: VisualJJ – Jujutsu in Visual Studio Code
#84There is no reason to use a VS Code extension, jjui is amazing! https://github.com/idursun/jjui
`jjui` is the best VCS TUI I've ever used, period. I tried `lazygit` and `magit` before and was not impressed.
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
Re: VisualJJ – Jujutsu in Visual Studio Code
#85stupid question: why do people want to move away from git? and why is this vcs being talked about a lot these days?
Git makes certain workflows more difficult than they could be. Using a different tool that makes you feel more productive is generally nice.
Re: VisualJJ – Jujutsu in Visual Studio Code
#86Earlier quoted context omitted.
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…
I'm quite surprised to hear that "programming languages have reached a terminal state": there are (imo) at least four in-progress movements in the industry right now: 1. Memory safety 2. Better metaprogramming capabilities 3. Algebraic effects 4. Solver/prover awareness Even if LLMs become capable of writing all code, I think there's a good chance that we'd want those LLMs writing code in a language with memory safet…
I didn’t quite mean that programming languages have reached their terminal state, although I understand how my comment was interpreted like that. I meant that programming languages, as we known them today, have reached a terminal state.
Using Rust as an example: Rust aims to provide memory safety at the expensive of developer ergonomics. Personally, I shy away from Rust because I don’t like fighting the borrow checker.
However, with AI agents, Rust could make a lot more sense. Strict errors at compile time are helpful to an agent, which is more than happy to smash its head against the wall until it reaches a working solution.
Following this logic, we could see languages develop that are extremely impractical for humans to use yet provide benefits like memory safety or correctness. But these languages might not look anything like the languages we’re currently used to.
Re: VisualJJ – Jujutsu in Visual Studio Code
#87Earlier quoted context omitted.
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 beco…
https://github.com/LucioFranco/jj-spr is one way to get stacked diffs on GitHub with jj, but also GitHub has at least claimed on X that native stacked diffs is coming so we'll see how that goes!
Re: VisualJJ – Jujutsu in Visual Studio Code
#88Earlier quoted context omitted.
I noticed it get a lot better with the 4.5 models specifically. Before then, I would have to tell Claude "do a web search for the docs for jj, then do XYZ." Now I just tell it to "do XYZ using jj"
do you use it with git worktrees? or how do you handle multiple claudes?
I use jj workspaces, which are pretty similar to git worktrees. But 95% of the time I just use one Claude.
Re: VisualJJ – Jujutsu in Visual Studio Code
#89Earlier quoted context omitted.
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?
Same way everyone else does it. You can't abstract away the underlying problem.
Re: VisualJJ – Jujutsu in Visual Studio Code
#90Earlier 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.
MCP solves the wiring problem nicely, but once you have more than one coding agent running, coordination becomes the real bottleneck.
I ran into repeated issues with agents editing the same files, losing decisions, and drifting away from the spec. I ended up building a small Rust MCP server that adds task claiming, file-level locking, and drift checks against SPEC.md.
It’s intentionally boring infrastructure… single binary, file-based state, deterministic orchestration. The AI tools stay interchangeable.
Repo if anyone’s curious: https://github.com/nxtg-ai/forge-orchestrator