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

▲

block_dagger 5 hours ago | parent | next [-]

Having no such thing as an uncommitted change seems like it would be a nightmare, but perhaps I'm just too git-oriented.

	▲	steveklabnik 4 hours ago \| parent [-]
		Things like the index become a workflow pattern, rather than a feature, if that makes any sense.

▲

MarkMarine 5 hours ago | parent | prev [-]

Also JJ undo is there and easy to tell the model to use, I have it in my Claude.md

	▲	hu3 2 hours ago \| parent [-]
		surely Claude is much better at using git because of the massive training data difference. If it didn't undo git, it would do it with JJ either.

▲

mbb70 6 hours ago | parent | prev [-]

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

▲

ewoodrich 5 hours ago | parent [-]

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.

	▲	foobar10000 4 hours ago \| parent [-]
		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...