←back to thread

I scanned all of GitHub's "oops commits" for leaked secrets

(trufflesecurity.com)
199 points elza_1111 | 2 comments | 03 Jul 25 06:44 UTC | HN request time: 0.478s | source
Show context
SillyUsername ◴[03 Jul 25 07:01 UTC] No.44452402[source]▶
Git never forgets, this isn't really a shocking revelation.
replies(3): >>44452453 #>>44452484 #>>44452485 #
eviks ◴[03 Jul 25 07:12 UTC] No.44452453[source]▶
What specific property of git mandates a website to not clean up those dangling commits?
replies(1): >>44452893 #
1. orthoxerox ◴[03 Jul 25 08:30 UTC] No.44452893[source]▶
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.
replies(1): >>44452937 #
2. eviks ◴[03 Jul 25 08:40 UTC] No.44452937[source]▶
> 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?