(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).
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.
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?
> you can manually stage against @-: [with jujutsu]
And what would that reason be? You can git revert a git revert.
And the reason jj helps in that case is that for jj there is no such thing as an uncommitted change.
If it didn't undo git, it would do it with JJ either.
Why? What's the problem you see? The only problem I see is when you let these extra commits pollute the history reachable from any branch you care about.
Let's look at the following:
Internally, 'git stash' consists of two operations: one that makes an 'anonymous' commit of your files, and another that resets those files to whatever they were in HEAD. (That commit is anonymous in the sense that no branch points at it.)
The git libraries expose the two operations separately. And you can build something yourself that works similarly.
You can use these capabilities to build an undo/redo log in git, but without polluting any of the history you care about.
To be honest, I have no clue how Jujutsu does it. They might be using a totally different design.
The problem is git's index let's you write a bunch of unconnected code, then commit it separately. To different branches, even! This works great for stacking diffs but is terribly confusing if you don't know what you're doing.
You just build commits, and then later on you muck around with the mutable pointers that are branches.
"later on" makes it sound to a human like it takes any real amount of time or that it isn't basically instant and wrapped by up porcelean, and "muck around with" implies that there's anything more random or complicated to it then writing the sha to a file in the right place in the .git directory.
Of course if you give an agentic loop root access in yolo mode - then I am not sure how to help...
Stop spamming
Especially not away from git.
Given that other posts solved the problem by scripting this feature on top of git, I guess you're telling them their solution isn't relevant too.