4 ms·
Lately I've been hearing more people are getting into jj because of how much easier it is to keep track of the code generated with tools like cursor or claude c
by fouc 1y ago
Lately I've been hearing more people are getting into jj because of how much easier it is to keep track of the code generated with tools like cursor or claude code.
- stouset 1y agoYes! I have found it incredibly helpful when using an agent. It's a great case for the "staging-area" style workflow. I `jj new` an empty revision where the LLM can go hog-wild. When I'm generally happy with the LLM's work, I make a new revision. Then I ask it to make some improvements. Sometimes I have to discard those. No problem, I just `jj abandon` the whole thing. Sometimes I like a few pieces; I `jj squash -i` those into the parent revision with the bulk of the work and abandon the rest. And then I repeat until I'm happy with the overall output. It's also super useful when I need to go fix something in an earlier (but still unmerged) revision. `jj new {id}` creates a new revision whose parent is the older change, even if it already has children. Again, I let the agent loose. When I'm happy, I `jj squash -i` what I want and the fixes are not only incorporated back into the parent but then propagated automatically down through the rest of its children through automatic rebasing.
- 1718627440 1y agoI wonder when LLMs will start messing with VCS. That will be fun :-/
- steveklabnik 1y agoMost coding llms already know git, and can handle jj pretty well too.
- 1718627440 1y agoI expect them to, I ment, that as part of modifying the code the issue commands that affect the VCS. This would be annoying, because you then can't rely on the VCS to tell you what the LLM did.
- stouset 1y agojj has the operation log, which is an append-only history of the entire set of interactions with the repo. So it’s there :)
- steveklabnik 1y agoSure, I'm not saying you should feel good or bad about it, I'm just letting you know that it is already there.