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.
> Having no such thing as an uncommitted change seems like it would be a nightmare, but perhaps I'm just too git-oriented.
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.
Yes, this exact scenario has happened to me a couple times with both Claude and Codex, and it's usually git checkout, more rarely git reset. They immediately realize they fucked up and spend a few minutes trying to undo by throwing random git commands at it until eventually giving up.
Yeap - this is why when running it in a dev container, I just use ZFS and set up a 1 minute auto-snapshot - which is set up as root - so it generally cannot blow it away. And cc/codex/gemini know how to deal with zfs snapshots to revert from them.
Of course if you give an agentic loop root access in yolo mode - then I am not sure how to help...
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?
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.
What were you trying to “revert back”? You should have been able to just stop using jj, there’s nothing to revert back to. It’s also possible that I’m misunderstanding what you mean.
Jujutsu doesn’t change your Git repository in incompatible ways. It just tracks extra information in the .jj/ directory. There is zero migration needed to revert back to Git – you just start using Git again.
Here in Ireland, night-time power prices are much lower than daytime.
I’m happy enough that a battery will serve me equally well in both modes, but there’s definitely going to be a period where all it does is support self-consumption.
The utility side has found that vaporising short circuits is a useful feature, as that includes e.g. twigs hitting a power line.
There are breakers, of course, but they react slowly enough that there will absolutely be a massive overdraw first. Then the breaker will open. Then, some small number of seconds later, it will automatically close.
It will attempt this two to four times before locking out, in case it just needs multiple bursts. It’s called “burning clear”, and it looks just as scary as you’d think… but it does work.
It's hard for me to imagine how machine learning Nobel Prize laureate Geoffrey Hinton, someone who is openly warning about extinction risk from AI, is some insane crank on the topic of... machine learning.
Same goes for Turing Award winner Yoshua Bengio, AI tech CEOs Dario Amodei, Sam Altman, Elon Musk, etc. who have all said this technology could literally murder everyone.
reply