Comment by hk__2
23 days ago
> The only other notable setback was an accidental use of the word "revert" which Codex took literally, and ran git revert on a file where 1-2 hours of progress had been accumulating.
23 days ago
> The only other notable setback was an accidental use of the word "revert" which Codex took literally, and ran git revert on a file where 1-2 hours of progress had been accumulating.
If I tell Claude to "revert that last change, it isn't right, try this instead" and Claude hasn't committed recently it will happily `git checkout ...` and blow away all recent changes instead of reverting the "last change".
(Which, it's not wrong or anything -- I did say "revert that change" -- it's just annoying. And telling `CLAUDE.md` to commit more often doesn't work consistently, because Claude is a dummy sometimes).
I haven't tried it, but theoretically one could use Claude Code's hooks facility to enforce committing at some determined thresholds.
I use it (with jj but should be the same with git). It tells Claude to commit after every Write tool use. It's a bit to small steps but I then usually just squash them afterwards. I haven't yet found a good automatic heuristic for when to tell Claude to commit (or directly auto-commit, but I like that Claude writes the commit message)
[dead]
Amazing that these tools don't maintain a replayable log of everything they've done.
Although git revert is not a destructive operation, so it's surprising that it caused any loss of data. Maybe they meant git reset --hard or something like that. Wild if Codec would run that.
I was looking at the insanity known as Gas Town [0] the other day, and it does use Git to store historical work state in something it calls "beads":
https://github.com/steveyegge/gastown?tab=readme-ov-file
If anyone is curious, Beads is an agent memory project from the same developer: https://github.com/steveyegge/beads
Bees?
1 reply →
I have had codex recover things for me from its history after claude had done a git reset hard, codex is one of the more reliable models/harneses when it comes to performing undo and redo operations in my experience.
Claude Code has had this feature for a few months now.
I found this tool to be the solution I was looking for to address this specific problem:
https://contextify.sh
Claude Code has /rewind. Not sure if it is foolproof, but this has been tried.
Huh, I didn't realize this existed. I feel like it's a miss that Claude doesn't use it when you tell it to undo its work.
It doesn‘t handle anything Claude uses the shell for, so if it runs `rm -rf .` then rewind won’t help you.
1 reply →
Claude (can’t remember if was 4.1 Opus, 4.5 Sonnet, or 4.5 Opus) once just started playing with git worktrees and royally f-d up the local repo and lost several hours of work. Since then, I watch it like a hawk.
`git reset --hard` doesn't remove unreferenced commits or rewrite the reflog so I don't think that would do it. Something like `git reset && git gc` would have to be done.
And git gc doesn't collect any garbage less than two weeks old by default, either.
But it does remove current uncommitted changes.
1 reply →
I wonder how they accidentaly used a word like that.
“Please revert that last change you did”, referring to like a smaller change that had just been done
Codex reverted kindly.
Does Codex not let you set command permissions?
Yea, it does so this would likely have been to be a `--yolo` (I don't care, let me `rm -rf /`). I've found even with the "workspace write" mode and no additional writable directories I can't do git operations without approval so it seems to exclude `.git` by default.
Yet another reason to use Jujutsu. And put a `jj status` wrapper in your PS1. ;-)
Start with env args like AGENT_ID for indicating which Merkle hash of which model(s) generated which code with which agent(s) and add those attributes to signed (-S) commit messages. For traceability; to find other faulty code generated by the same model and determine whether an agent or a human introduced the fault.
Then, `git notes` is better for signature metadata because it doesn't change the commit hash to add signatures for the commit.
And then, you'd need to run a local Rekor log to use Sigstore attestations on every commit.
Sigstore.dev is SLSA.dev compliant.
Sigstore grants short-lived release attestation signing keys for CI builds on a build farm to sign artifacts with.
So, when jujutsu autocommits agent-generated code, what causes there to be an {{AGENT_ID}} in the commit message or git notes? And what stops a user from forging such attestations?
- "Diffwatch – Watch AI agents touch the FS and see diffs live" (2025) https://news.ycombinator.com/item?id=45786382 :
> you can manually stage against @-: [with jujutsu]
> Yet another reason to use Jujutsu
And what would that reason be? You can git revert a git revert.
You're correct for an actual git revert, but it seems pretty clear that the original authors have mangled the story and it was actually either a "git checkout" or "git reset". The "file where 1-2 hours of progress had been accumulating" phrasing only makes sense if those were uncommitted changes.
And the reason jj helps in that case is that for jj there is no such thing as an uncommitted change.
11 replies →
Probably it actually ran git checkout or reset. As you say git revert only operates on committed snapshots so it will all be in the reflog
2 replies →
It's not going to happen...
Stop spamming
The feature of "there is no such thing as an uncommitted working directory" is very relevant to the situation.
3 replies →
This is funny. I tried it once and didn't see what the benefit was. Then, when I tried to reset it back to normal git, I realized that the devs had not (at the time) made any clean way to revert it back, just a one-way conversion to jj. I haven't tried it since.
2 replies →