[keybored]

It’s not necessarily the only use case.

But as I’ve read (according to Martin) doing it this way simplifies the implementation a lot. You track everything directly in the DB. In turn you don’t have to care about all sorts of states like being in conflicted git-am state, conflicted git-merge, etc.—these states cannot happen, it’s all in the DB (not some dirty working tree state where some flags or files somewhere in `.git` or `.jj` tell you “there are some conflict markers thereabouts, enjoy”).

And that frames it in terms of being easier for the people implementing jj. But I think it will also benefit us users by making it easier for them to create streamlined tools.

git-rebase(1) and all that is great and all. But definitely messy. And we only recently got `--update-refs` to update dependent branches, which is kind of late considering how important branches are in Git.