Claude Code Checkpoints

I don't know what this is but isn't git enough? Incidentally I'm not convinced in my day-to-day for "jujitsu" (jj) but from what I understand about how it works, I've been wanting to give it a try for agent-based coding, based on the way it defaults to saving everything and letting you sort it out after. I do like how Aider commits everything so you can easily roll back, although it ends up with a few too many commits imho.

I've been wanting to experiment also with getting an agent to go back and rebase history, rewrite commits etc in the context of where the project ended up, to make a more legible history, but I don't know if that's doable, or even all that useful.

I don't think jujutsu woild help with this use case -- jujutsu will not save everything because it is not running constantly on your repo. It snapshots the working tree only when you run a `jj` command. Ineffective if an agent is doing work.

You can use Claude hooks ( https://docs.anthropic.com/en/docs/claude-code/hooks#stop-an... ) to trigger jj / git automatically.

I recently started using Aider and had that thought about too many commits. What I realized though was: (1) if I'm going to contribute to a project, I should be working in a local branch and interactively rebasing to clean up my history anyway (and of course carefully reviewing Aider's work first) and (2) if I'm working on my own thing WITHOUT LLM, I tend to prefer to commit every dang little change anyway, I just don't remember to do it because I'm in the zone and then inevitably wish I had at some point.

Yea but then you need need to commit each iteration of each file right away, even if its not working.

Its fine if you just rebase at the end manually, but not good if you don't, your history will be cluttered and as hard to read as the codebase.

Eventually most people who use coding tools will have low knowledge of what is being generated and then they probably never rebase either...

Git won't catch new files the agent is adding. To get around that you can of course always add all new files, but then you'll potentially have your repo polluted with a bunch of temporary scratch files instead.

You can typically go back and edit git history. But it will require force push and breaking changes. And a few sacrifices to ensure that it doesn't make a mistake because then your repo is potentially broken.

Best way to do that is probably to have it work on branches and then squash merge those.

You could also create a branch, save your intermediates there, and then squash merge when you are ready.

> Git won't catch new files the agent is adding.

Another problem I inadvertently dodged by using Jujutsu with Claude Code :)

I tend to send a lone "commit" message to Claude when I think I'm in a spot I may want to return to in the future, in case the current path doesn't work out. Then Claude commits it with a decent message. It knows how to use jj well enough for most things. Then it's really easy to jj new back to a previous change and try again.

Exactly. This is precisely what I do.

Yup, that's what I do. Even for personal projects, with the flurry of changes Claude/other AI assistants make, a branch makes it easier for me to compare changes.

Often I have a branch with multiple commits on it, with each commit corresponding to a message in a conversation with AI on Cursor trying to get a new feature built.

In the end, I can diff the branch against the main branch, and see the sum total of changes the AI agent has made.

Maybe edit/improve manually on my own afterwards. And then, merge.

I always squash and reorganise the commits from aider. It is however awesome that everything is in git directly from the agent. I can’t imagine why not all these tools do this!

> I tend to prefer to commit every dang little change anyway, I just don't remember to do it because I'm in the zone and then inevitably wish I had at some point.

That’s what I do too until I developed a practice to break up into thematic commits as I realize I need them. And if I don’t, then I just git reset to the beginning and use git gui to commit lines and chunks that are relevant for a given piece of work. But with experience, I barely do the break down completely - I generally don’t even bother creating commits until I have a starting sense of what the desired commit history should be.

Yup, just rebase.

I just commit with a “wip!”-prefaced message whenever the LLM pauses and says it’s finished, including new files. You can squash and cleanup later, or revert back to a state before it screwed up.

Also doubles as a way to cohesively look at the changes it made without all the natural language and recursive error/type fixing it does while working.

I don’t understand why people are making it so complicated. You’re saving a minute per iteration with the LLM, tops, at risk of losing control or introducing hard to find issues. It is the definition of diminishing returns.

uhh... .gitignore solves that right?

I sometimes use jj in watcher mode and then just use the oplog to go back to wherever.

you can set up the watchman fs monitor to snapshot whenever a file changes on the filesystem, its saved my ass plenty of times

These agents often generate randomly named files and dump them anywhere. You can end up with dozens of files added if you let it run on any problem it tries to create one-off "test / reproduction" cases. It hasn't always cleaned them up so a "git add all" approach can bring in junk, and the patterns for names aren't consistent. In fact they're often called stuff like *-test.js which looks like it could be a source OR test file.

That's why I wouldn't recommend "git add all", but rather use something like gitextensions [0] and visually add files or delete them, so you know what's happening in git world.

[0] https://gitextensions.github.io/