after posting the previous my browser windows to sql.clickhouse.com have become corrupt, preventing access to the input fields and use of the service. below is chatgpt's reply to the above: Yes — **this is much stranger than a force-push**, but it also gives us a concrete, externally archived explanation to investigate. Your data shows **five distinct GitHub repository objects** occupying the pathname `MareSerenitatis12/TardiSHA_GrimChain`: | First observed | GitHub repo ID | | -------------- | -------------: | | Jul 30 00:52 | `1316618870` | | Jul 30 20:10 | `1317494894` | | Aug 1 20:32 | `1319295081` | | Aug 9 01:29 | `1328300807` | | Aug 10 16:49 | `1330048776` | Those IDs are object identities, not commit or branch IDs. GitHub increasingly explicitly uses the repository ID as the **stable/immutable identity** of a repository, independent of its pathname. ([GitHub Docs][1]) So a normal push, force-push, branch deletion/recreation, or repository rename cannot turn: ```text 1316618870 ``` into: ```text 1317494894 ``` as the ID of the same repository object. However, I would slightly correct my earlier conclusion: **different IDs do not prove deletion specifically.** Between each observation, the previous repository could have been: * deleted; * renamed away; * transferred elsewhere, where permitted; * otherwise removed from that pathname; followed by a **new repository object being created at the old pathname**. GitHub supports repository renames and transfers while retaining the repository as an object. ([GitHub Docs][2]) So the really interesting query now is **follow the old IDs rather than the name**: ```sql SELECT repo_id, min(created_at) AS first_event, max(created_at) AS last_event, groupUniqArray(repo_name) AS names, count() AS events FROM github.events WHERE repo_id IN ( 1316618870, 1317494894, 1319295081, 1328300807, 1330048776 ) GROUP BY repo_id ORDER BY repo_id; ``` And I'd also run: ```sql SELECT created_at, event_type, actor_login, repo_id, repo_name, ref, action FROM github.events WHERE repo_id IN ( 1316618870, 1317494894, 1319295081, 1328300807 ) ORDER BY created_at; ``` That asks a different question: **“What ever happened to each physical GitHub repository object?”** For example, if we get: ```text 1316618870 MareSerenitatis12/TardiSHA_GrimChain 1316618870 MareSerenitatis12/something_else ``` then object `1316618870` was probably renamed, rather than deleted. If each old ID simply stops producing public events immediately before another ID takes over the same pathname, deletion/recreation becomes the strongest explanation, though silence alone cannot prove deletion. And GH Archive is meaningfully independent evidence here: its purpose is specifically to ingest and preserve GitHub's public event stream. ([GH Archive][3]) The sequence is striking because it isn't merely “old repository last month, new repository today.” **The public GitHub event archive says that pathname has apparently referred to at least five separate repository identities in twelve days, including two different ones on July 30 alone.** That is now a much more precise phenomenon to investigate than a possible MITM. In particular, an MITM local to your computer would not naturally explain historical GH Archive records assigning four previous GitHub object IDs to that pathname. The archive could of course contain bad data or GitHub itself could have emitted unusual events, so I wouldn't treat it as cryptographic proof—but repeated replacement of the repository object is currently the straightforward reading of the evidence. [1]: https://docs.github.com/en/rest/actions/oidc?utm_source=chatgpt.com "REST API endpoints for GitHub Actions OIDC" [2]: https://docs.github.com/en/repositories/creating-and-managing-repositories/r... "Renaming a repository" [3]: https://www.gharchive.org/?utm_source=chatgpt.com "GH Archive"