3 ms·

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 work

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.

mfenniak 1y ago
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.
- adobrawy 1y ago
  You can use Claude hooks ( https://docs.anthropic.com/en/docs/claude-code/hooks#stop-and-subagentstop-input https://docs.anthropic.com/en/docs/claude-code/hooks#stop-an... ) to trigger jj / git automatically.
- ricericerice 1y ago
  you can set up the watchman fs monitor to snapshot whenever a file changes on the filesystem, its saved my ass plenty of times
jtickle 1y ago
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.
- vlovich123 1y ago
  > 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.
hoppp 1y ago
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...
- samtheprogram 1y ago
  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.
mhast 1y ago
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.
- fluidcruft 1y ago
  You could also create a branch, save your intermediates there, and then squash merge when you are ready.
  - skapadia 1y ago
    Exactly. This is precisely what I do.
  - winter_blue 1y ago
    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.
- fprotthetarball 1y ago
  > 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.

mfenniak 1y ago

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.

adobrawy 1y ago
You can use Claude hooks ( https://docs.anthropic.com/en/docs/claude-code/hooks#stop-and-subagentstop-input https://docs.anthropic.com/en/docs/claude-code/hooks#stop-an... ) to trigger jj / git automatically.
ricericerice 1y ago
you can set up the watchman fs monitor to snapshot whenever a file changes on the filesystem, its saved my ass plenty of times

jtickle 1y ago

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.

vlovich123 1y ago
> 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.

hoppp 1y ago

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...

samtheprogram 1y ago
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.

mhast 1y ago

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.

fluidcruft 1y ago
You could also create a branch, save your intermediates there, and then squash merge when you are ready.
- skapadia 1y ago
  Exactly. This is precisely what I do.
- winter_blue 1y ago
  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.
fprotthetarball 1y ago
> 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.