Comment by entrope

That's one of the nice features of jj: instead of having an index, the working tree is its own commit, and it tracks the history of that when you run most jj commands.

This works because each commit gets a "change id" assigned that only changes when you say. When you create a new commit, edit its commit message, and edit files, you end up with three git commits with the same change id, but two of the git commits will be gc'ed eventually. (The change id is what you normally use to identify what's in the git commit graph.)

So even if you issue a command that destroys overwrite some important changes, jj has a good chance of remembering your worktree state.