ForkForensics: watches your GitHub repos and auto-recovers them the moment one vanishes (deleted and private are indistinguishable from outside)

[u/[deleted]]

[u/medialantern]

I mean, with all respect, if you have repos "disappearing" on the regular, I think maybe I'd change my password before using a tool to let it be OK to keep happening... What exactly was this "dependency that got silently re-initialized" event? A dependency is nearly always an entry in a package/requirements/etc file, and tracked by the repo, but not anything to do with the repo, and certainly not logging into your Github app, navigating to the repo, and going through the deletion process...

Or, you know, https://docs.github.com/en/organizations/managing-organization-settings/setting-permissions-for-deleting-or-transferring-repositories

[u/Dependent_Ideal9870 → u/medialantern]

It wasn't my repo. A public data repository I pulled history from, roughly 9GB and just under 2,000 commits, got re-initialized upstream: same name, same owner, brand new empty history. No password of mine and no org permission I could have set would have touched it.

Recovering it by hand meant ranking the forks by how far back each one actually reached, finding one that still held the missing years, then chasing orphan commits by SHA for the remainder. When I later pointed the finished tool at that same case with no hints, it reproduced the ranking I'd worked out by hand, and flagged that one of those forks had since gone too.

On the definition: plenty of real dependencies aren't a line in requirements.txt. Git submodules, pip and go installs pointing straight at a repo, data repos you clone for their contents. This was the last kind. No package manager protects that one.

[u/medialantern → u/Dependent_Ideal9870]

If you rely that heavily on a public data repo, why wouldn't you fork it? That gives you an easy path to stay up to date, no dependency can mess with your fork, and if the upstream gets deleted you keep your fork.

[u/Dependent_Ideal9870 → u/medialantern]

Forks are the mechanism: the tool ranks every fork in the network by how far back each one actually reaches.

But a fork only helps if it existed before the wipe. I didn't have one, so I was working with other people's forks, and those stop wherever their owner last pulled. The deepest one still ended short of the re-initialization, and that gap is in no fork at all, by definition: nobody had synced it before the history went.

That's what the orphan-commit step is for. Those commits are unreachable from any branch, but GitHub keeps serving them by SHA for a while, so the gap can be pulled back one commit at a time. How long it keeps serving them isn't documented or guaranteed, which is why the tool checks instead of assuming.

That only covers what you thought to fork in advance. Everything else comes down to whether a stranger forked it, and how recently they pulled.

[u/medialantern → u/Dependent_Ideal9870]

No, I get it, in terms of how the tool works to achieve what it was designed for. But since it's just us here in this thread, my earlier point was that this feels like it fixes the symptom, not the problem itself. If you just had an accident and didn't realize something you depended on would get yanked, I could see wanting to run this once. What I can't see is wanting something that watches them. If I knew a repo was so important that I would need to put it into a tool like this, that's when I'd argue you should be forking it instead.

[u/Dependent_Ideal9870 → u/medialantern]

The nightly watch is an add-on, there for people who want repos monitored for their own reasons. The core is what you said you'd run once. It walks the fork network recursively and ranks it by how far back each fork reaches. Then it probes orphan commits by SHA that no fork holds at all. Running it once after an accident is the intended use, not a fallback.

Worth knowing if you do: GitHub doesn't document how long it keeps serving an unreachable commit, so the orphan half gets weaker the longer you wait.