Related Objects
Event Timeline
This is probably quite complicated, since it's hard for us to detect that commits are gone from a repository.
For one, we probably should not destroy Commit objects when the underlying commits are destroyed, but mark them with some isSpookyGhost flag, to preserve any metadata (links, transactions, comments) on them. This will also let you fix a mistake by pushing the correct commits back (if the force push was an error) without losing everything. In the UI, we would call out "spooky ghost" commits as "this previously existed, but now it is gone".
A good first step might be to build a bin/repository sync workflow or similar, which just checks that every commit in the repository still exists, and flags it as a spooky ghost if it does not. This could be slow and iterative, and would solve the original problem in this task. (With a tweak to the summary query to make it only count non-spooky commits).
Daemons could then be adjusted to bail gracefully when encountering spooky ghosts, and other tools like bin/repository importing and the importing count queries could be aware of them.
Finally, we could trigger some kind of spooky ghost process when we saw a non-fastforward branch operation during an update. It would take the old branch head and walk backward from it, identifying and marking spooky ghosts. Once this worked properly, sync could be a pure debugging flow.