Git does forget, it has a gc mechanism specifically for forgetting.

GitHub can't use the native git gc, and apparently doesn't have their own fork-aware and weird-cross-repo-merge-aware gc, so they might just not have built a way to track which commits are dangling.

But that's not obvious at all.

How to make git an elephant: https://donatstudios.com/yagni-git-gc

Ah right, so forking the codebase, then deleting the original repo forces git to forget all copies. Gotcha thanks for the enlightenment.

Git is not point in time backups. It is versioning.

You are free to organize your version history as you fit, and you can certainly rewrite history.

The only issue you might have is signed commits from collaborators, that you can not resign.

> and you can certainly rewrite history.

But you can't coerce everyone in the world to remove all traces of the alternate history that was a thing before being rewritten.

So while you can make git forget something in your local repo, you can't make git forget across the decentralised set of repos, which is part of git's core design.

So in that sense, yes, git never forgets, by design.

What specific property of git mandates a website to not clean up those dangling commits?

Git has no de jure hierarchy of repositories. We de facto treat the GH repo as the primary one (and call it "origin"), but mechanically it's a peer repo. Even though it lets other repos push it around a bit and obeys commands like "change the branch to point to another commit", there are no commands to force it to delete the data.

> Even though it lets other repos push it around

So there is hierarchy

> there are no commands to force it to delete the data.

That's just the current state, the question was how git prevents "de facto" deletion on a server? How is it anti-git to ask the server to execute git garbage collection commands, for example?