reflog can't quite catch every change that might happen because not everything is stored directly as a ref (ie a "head" that git tracks, like a branch pointer).

For instance, if you are interactively using `git bisect` and you mark commits as good or bad, and you accidentally mark a commit incorrectly, you have to do something like:

    git bisect log > /path/to/file.txt
    git bisect reset
    # modify file.txt to "look correct"
    git bisect replay /path/to/file.txt

The reflog can't really capture this kind of thing, hence why you have a bisect log -- now a wholly separate concept that exists independently of the reflog.[1]

Another example is when you do something like screw up an interactive rebase. Let's say you rebase 20 commits and then you get a conflict on commit 8. You fix the file conflicts, and continue. You accidentally solve the merge incorrectly, continue and get another conflict -- but only realize your mistake after you start solving it. The reflog can't save you here. You have to completely abandon the rebase and start over. (This specific example might be handled better these days).

I think the biggest thing about `jj undo` is that it works everywhere. You can undo rebases, merges, conflict resolutions, copies, deletions, whatever. The secret behind it all is that internally, jj is architected in a way where implementing a feature looks like you are working with a transactional database. You actually have `begin_transaction()` and `commit()` methods in the codebase that will make changes to the commit graph visible in an atomic way. When a command like `jj rebase` happens, all of the changes it makes are inside a transaction and committed at once. Every operation in the repo is a transaction, and it all goes into a log, which records the effects of a transaction -- very much like a database system!

So "undo" just means "undo the effects recorded in a transaction" and that is about all. And so it works for everything! And this design is very easy to intuitively understand and program against, as a maintainer, along with our other high level internal APIs. Any developer can easily write code that Just Does The Right Thing and the user can undo it and it's no big deal. When I develop and work on Jujutsu myself -- like I'm actively developing new features or prototyping ideas -- I almost always _use my own jj repository_ as a test repo while testing my builds.

In contrast, Git does not have one unified "transactional" layer for things like this. But not all is lost, there has been work on 'git undo' and it was implemented by... Someone who is now a Jujutsu maintainer[2]. :)

[1] Technically we do not yet have "step by step" bisect with good/bad yet (only "automatic" bisect that is one-shot), so that is something Git can do we can't do at all right now, but bear with me. :')

[2] https://blog.waleedkhan.name/git-undo/

The creator of Jujutsu has joined ERSC