People in this thread seem to be too focused on the agent creating a git log. This seems to be solving a different problem than that does.
When you're interacting with agents, multiple prompts may reasonable culminate in a single commit. It may be useful to track or undo things between commits - at the prompt level. I personally have a workflow when I use Jujutsu (jj) for git already, and this slotted in very nicely to solve this problem. The auto-committing in jj makes it very easy and natural to compare diffs between prompts, and undo specific chunks or restore previous states without making a new commit every prompt. I only finish a commit, giving it a message and advancing the branch, once I've iteratively dialed in the changes I want.
I probably won't use this tool since I already have a flow that works for me, but maybe this will help people see why such a tool can be helpful.
Sure. I was a bit loose with my vocab in my previous comment - I'm going to try to be more specific by using the terms as defined in the jj glossary[0] (particularly "change" vs "commit").
- I start by using jj new to create a new change where I want to start working.
- I open codex, and prompt it to do something.
- Roughly every prompt, I will naturally check the cumulative diff using jj diff.
- If I want to check the diff log of the working change, I'll use jj evolog.
- If I want to check the diff from the previous prompt, I'll use jj diff -f xx/1, where xx is the short change ID for the working change, and 1 is how many prompts ago I want to look at the diff for (jj evolog can help with finding the change I'm interested in)
- If I want to undo all or some of what a prompt did, I'll use jj restore -f xx/1, potentially with -i or a fileset.
- When I've prompted / restored / made changes myself to the point where I am happy with a change, I'll usually ask codex to write a conventional commit message for <commit_id>. Codex will then use *git* to look at the diff in that commit (which has no commit message), and give it will usually give an appropriate commit message[1] (sometimes I'll tweak this if there are details I want to add or remove). I use jj ci (short for jj commit) to finish the change and add the commit message.
- I'll then advance bookmarks as necessary with jj b m (short for jj bookmark move) and probably push.
Very interesting. I've been using org-roam for a while without too much trouble, but I do think a ripgrep backed system over a sqlite based one sounds interesting. I will have to see if I can port my notes over and try it out.
I've been using Qwen 3.5 and then 3.6 27b Q4 on Ollama with a single 7900 XTX with the codex cli, and I have been blown away by how genuinely useful it is. I've been able to ask it to do long, multi step problems, and it's able to do things that would have likely taken me days to iron out in a matter of hours, or even minutes sometimes.
I get about 30 tok/s, which is far from blazing, but given the capability it has it is absolutely viable for accelerating my work.
reply