71–80 of 90 posts
Earlier quoted context omitted.
Claude Code has zero issue using jj, for what it’s worth.
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"
There is no reason to use a VS Code extension, jjui is amazing! https://github.com/idursun/jjui
Earlier quoted context omitted.
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…
You can set jj to auto update stale workspaces btw
It might be ok for human use, but I have definitely seen agents in one workspace start encroaching on another workspace's turf. (Rare, but it's a huge pain to fix when it happens.)
Earlier 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.
This doesn't involve git use at all.
Even with multiple workspaces (like git worktrees), once you use something like jjk, both the agent and jjk in the associated VS Code are operating on the same workspace, so that doesn't isolate enough. I don't think jjk uses `--ignore-working-copy` for read-only status updates, so it's snapshotting every time it checks the repo status while the agent is editing.
On top of that, throw in whatever Claude does if you "rewind" a conversation that also "reverts" the code, and agents wrongly deciding to work on code outside their focus area.
It's possible watchman helps (I need to look into that), but I'm so rarely using jj in VS Code (all I really want is inline blame), that it was easier to remove jjk than try to debug it all.
Divergence won't hide or lose any work, but it's an annoying time-suck to straighten out.
Earlier quoted context omitted.
While the primary maintainer is a Google employee, the majority of commits and committers are not. It's decidedly not a Google project.
I mean the Google CLA kind of says otherwise.
If anybody is hesitant give it a try!
Earlier 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.