Feier zur Erstellung des milliardsten Repositorys auf GitHub

 (github.com/AasishPokhrel)
2 Punkte von GN⁺ 2025-06-12 | 1 Kommentare | Auf WhatsApp teilen
  • Der GitHub-Nutzer jonmagic gratulierte in Issue #1 zur Erstellung von GitHubs milliardstem Repository und teilte mit, dass das Repository shit diese ID habe
  • Als Beleg wurde eine curl -s-Antwort angeführt, die id 1000000000, node_id R_kgDOOO5rKAA, name shit und full_name AasishPokhrel/shit enthält
  • Der Kommentarverlauf setzte sich vor allem aus Glückwünschen und Scherzen rund um den Repository-Namen und das 💩-Emoji zusammen; auf den ursprünglichen Beitrag entfielen Tausende 👍-, 😄- und 🎉-Reaktionen
  • jonmagic hinterließ einen Link zur GitHub-Dokumentation mit dem Hinweis, dass der Repository-Eigentümer bei Bedarf die Konversation sperren oder das Abonnement beenden könne
  • Am 28. Juni 2025 sperrte der Repository-Eigentümer die Konversation und beschränkte sie auf collaborators; am selben Tag wurde ein Kommentar gelöscht

shit als angeblich milliardstes Repository

  • Der Issue-Titel lautet Congratulations on creating the one billionth repository on GitHub! und gratuliert zur Erstellung von GitHubs milliardstem Repository
  • jonmagic gratulierte dem Ersteller des Repositorys und führte dafür unter anderem das Ergebnis des folgenden API-Aufrufs an
  • Die Glückwunschbotschaft enthält ein Wortspiel mit dem Repository-Namen, sinngemäß in der Art: Man hoffe, dass daraus großartiger 💩 entstehe

Reaktionen und Scherze in den Kommentaren

  • Die frühen Kommentare bestanden größtenteils aus Glückwünschen und Wortspielen
    • „Bin gespannt, was für großartiger 💩 daraus wird“
    • „Ich kann es kaum erwarten, bis dieser 💩 durchstartet“
    • „Ich werde das forken“
    • „Ich hinterlasse einen Kommentar, bevor dieses Issue gesperrt wird“
  • MangoCubes schrieb, beruhigt zu sein, dass jonmagic ein GitHub-Mitarbeiter sei
  • jordigh parodierte das typische Format von Issue-Kommentaren mit einer Frage nach einem „voraussichtlichen Termin für einen Fix oder einem Workaround“
  • Danach folgten weitere kurze Kommentare wie 💩, sssssssshit und „peak shit“

Hinweis zur Benachrichtigungsflut

Umfang der Beteiligung und Reaktionen

  • Im ursprünglichen Issue-Text werden Tausende von Reaktionen angezeigt
    • 👍 4524
    • 😄 2116
    • 🎉 2638
    • ❤️ 945
    • 🚀 1201
    • 👀 611
  • In der Mitte der Kommentarliste erscheint der Hinweis, dass 1136 weitere Einträge vorhanden sind, sodass nur ein Teil der Kommentare sichtbar ist
  • In den Metadaten werden einige Teilnehmende sowie +1092 angezeigt

Sperrung und späterer Status

  • Am 28. Juni 2025 sperrte der Repository-Eigentümer die Konversation und beschränkte sie auf collaborators
  • Am selben Tag wurde ein Kommentar von luckydonald gelöscht
  • Am unteren Ende des Issues erscheint der Hinweis, dass man sich registrieren oder anmelden müsse, um an GitHub-Konversationen teilzunehmen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-12
Meinungen auf Hacker News

  • Ich musste an den 100-millionsten Changeset von OpenStreetMap denken.
    Ein paar Leute, mich eingeschlossen, hatten locker darauf spekuliert, aber am Ende ging er nicht an jemanden, der es darauf angelegt hatte, sondern an jemanden, der fleißig Karten in Afrika zeichnete.
    Im Nachhinein war das ein viel schöneres Ende, und die Person war zuvor sogar schon einmal für einen OSM-Award nominiert worden.
    Bei OpenStreetMap sind alle Daten echte Betriebsdaten, daher ist es schwer, einfach irgendwelche Müll-Daten zu erzeugen; deshalb ist es wohl wahrscheinlicher, dass der N-te Commit aus einer spontanen Arbeit von jemandem stammt.
    Auch für GitHub ist das ein netter Meilenstein :)
    Wer mehr über den OSM-Meilenstein lesen möchte: der offizielle Blogbeitrag: https://blog.openstreetmap.org/2021/02/25/100-million-edits-...
    Meine Zusammenfassung der damaligen Changeset-Aktivität: https://www.openstreetmap.org/user/LucGommans/diary/395954

    • Ein Freund von mir hat früher einmal einen ganzen Arbeitstag darauf verwendet, unser einmillionstes Helpdesk-Ticket zu erstellen.
      Ich weiß nicht mehr, wie er es letztlich geschafft hat, aber das Team hat sogar eine kleine Party veranstaltet, um diese Leistung zu feiern.
      Das ist wohl etwa 15 Jahre her; damals fühlte sich die Arbeit in der Tech-Branche irgendwie spaßiger an.

  • Cool! Selbst GitHubs eigene OpenAPI Spec hat nur noch etwas mehr als eine Milliarde Repositories vor sich, bis bei Repositories ein int32 überläuft.
    Bei Workflow-Run-IDs passiert das bereits.
    https://github.com/github/rest-api-description/issues/4511

    • Als ich zu einem Unternehmen kam, bei dem ich kurz als CTO gearbeitet habe, hatte eine zentrale Tabelle bereits 1,3 Milliarden Zeilen, verwendete aber 32-Bit-Integer als Primärschlüssel.
      Bei der damaligen Wachstumsrate wären die Primärschlüsselwerte innerhalb weniger Monate übergelaufen, daher haben wir ziemlich dringend ein Projekt gestartet, um die IDs auf 64 Bit umzustellen und eine Katastrophe zu vermeiden.
    • Vor ein paar Wochen hatte die Lua-Community ein kleines Problem, als LuaRocks die Marke von 65.535 Paketen überschritt.
      Diese Zahl kollidierte mit der LuaRocks-Implementierung in LuaJIT [1] [2], und einige CI/CD-Pipelines und persönliche Workflows von Nutzern fielen aus, was schmerzhaft war.
      Es wurde recht schnell behoben, war aber eine interessante Sache.
      [1] https://github.com/luarocks/luarocks/issues/1797
      [2] https://github.com/openresty/docker-openresty/issues/276

  • Ich wünschte, ich wäre noch bei Apple.
    Die meisten hier wissen vermutlich, dass Apple seit Langem ein internes Tool namens Radar verwendet.
    Jeder Radar hat eine ID, also eine Bug-Nummer.
    Ein Radar wie Bug #1,000,000 war ziemlich besonders.
    Sofern nicht jemand versehentlich das ganze Team enttäuschte, war es normalerweise ein Fake-Radar voller Insider-Witze.
    Schon einen einzigen zu öffnen reichte eigentlich, aber weil Radar auf andere Radars verweisen konnte, landete man von dort meist in einem Rabbit Hole und hatte seinen Spaß.
    Es war wirklich dumm von mir, nicht wenigstens ein paar davon zu capturen oder auszudrucken, als ich die Gelegenheit hatte.

    • Auch Googles Versionsverwaltungssystem für das Monorepo vergibt für jede Änderung so eine monoton steigende ID.
      Leider haben vor ein paar Jahren, als eine runde Zahl näher rückte, Leute Skripte laufen lassen, um genau diese ID zu erwischen, wodurch das System in einen Denial-of-Service-Zustand geriet.
      Daher werden IDs in der Nähe großer runder Zahlen heute übersprungen :(
      Darin steckt vermutlich eine Lektion zum Schema-Design.
    • Andererseits: Wenn man bedenkt, wie Apple mit vertraulichen Daten umgeht, hätte ich wohl nicht dabei erwischt werden wollen, interne Dokumente herauszuschmuggeln, egal wie harmlos sie aussahen.

  • Apropos GitHub-Repository-IDs: Das erste Repository ist hier:
    https://api.github.com/repositories/1
    https://github.com/mojombo/grit

  • Vermutlich hat jemand per Skript wiederholt https://api.github.com/repositories/999999999 abgefragt und in dem Moment, in dem es auftauchte, ein neues Repository erstellt.
    Repositories lassen sich bearbeiten, also könnte die Person auch mit etwas Puffer mehrere erstellt und dann die gelöscht haben, die nicht die richtige Nummer hatten.
    Wenn man sich die anderen Repositories ansieht, die der Autor gestern erstellt hat, war „yep“ wohl die magische Zahl, und „shit“ vermutlich das Eingeständnis, dass es danebenlag.
    Erinnert sich noch jemand an Facebooks D666666?
    Das war eine riesige Code-Transformation, und der Autor nutzte eine ähnliche Technik, um eine bestimmte Nummer zu bekommen.

    • Oder vielleicht auch nicht.
      Ich weiß nicht, warum man annimmt, dass diese Person absichtlich genau dieses Repository erwischt hat.
    • Es ist ein leeres Repository, also scheint es zu stimmen.

  • Im Ernst: Ich bin ein wenig überrascht, dass GitHub es so einfach gemacht hat, die Rate zu berechnen, mit der neue Repositorys erstellt werden.
    Sind solche Informationen nicht normalerweise ein Geschäftsgeheimnis?

    • Wenn der Burggraben eine Milliarde breit ist, läuft man wohl auch mal in Unterwäsche herum.
    • Gibt es einen Grund, warum GitHub diese Information verbergen sollte?
      Ich sehe nicht, wie man das zum Nachteil von GitHub nutzen könnte.
      Ich verstehe, dass viele Unternehmen standardmäßig keinerlei Informationen veröffentlichen, solange sie nicht dazu gezwungen sind.
    • Mit binärer Suche lässt sich auch die neueste ID extrem schnell finden.
      Früher habe ich auf diese Weise das Wachstum mehrerer Websites verfolgt.
    • Man kann auch die Rate sehen, mit der neue Nutzer angelegt werden.
      In gewisser Weise ist das sogar interessanter.

  • Ich frage mich, ob AasishPokhrel dieses Repository erstellt hat, um das milliardste Repository zu werden.

    • AasishPokhrel hat gestern zwei Repositorys erstellt, „shit“ und „yep“.
      Zwischen dem 17. Mai und dem 10. Juni gab es keine Aktivität.
      Ich weiß nicht, ob man die Erstellungsrate von Repositorys berechnen und dann ein Repository genau zur gewünschten Nummer anlegen kann.
    • Das lässt sich ziemlich leicht manipulieren.
      Man erstellt einfach weiter Repositorys, bis das milliardste dabei ist, und löscht dann die vorherigen.
      Mit der GitHub API ist das sehr einfach.
      Das Einzige, was im Weg steht, sind Rate Limits und andere Leute, die gleichzeitig Repositorys erstellen; am Ende ist es also Glückssache.
    • Er scheint ein Student aus Nepal zu sein, der Softwareentwicklung studiert, und es ist wirklich bewegend, dass ein solcher Meilenstein bis in entlegene Teile der Welt reichen kann.
      Ich hoffe, er schreibt das groß in seinen Lebenslauf und findet eine gute Karriere in der Entwicklung.
    • Sehr verdächtig, aber es scheint möglich zu sein.

  • Der Name dieses Repositorys wurde geändert, und es scheint jetzt auf https://github.com/AasishPokhrel/repository/ weiterzuleiten.
    Nicht so toll :-(

    • Es wurde wieder auf den ursprünglichen Namen zurückgeändert! :-D

  • Ich frage mich, wie viele Repositorys es insgesamt wären, wenn man lokale Forgejo- und GitLab-Server mit einrechnet.
    Einschließlich Subversion, Mercurial, anderer Freunde von git und sogar seiner Feinde.
    Hat schon jemand eine Suchmaschine für so etwas gebaut?
    Es wäre schön, nach einem Wort wie „a“ suchen zu können, um die Größenordnung grob abzuschätzen.
    Ein großer Vorteil des zentralisierten GitHub schien immer zu sein, dass Leute meinen Code tatsächlich finden können.
    Nachdem Microsoft GitHub übernommen hatte, habe ich darüber nachgedacht, eine Suche zu bauen, habe es aber letztlich gelassen, weil ich mit dem Marketing nicht fertig geworden wäre und es wohl vergebliche Mühe gewesen wäre.
    In letzter Zeit habe ich mehrere Projekte auf Codeberg gestellt und wieder darüber nachgedacht, ob es sich lohnen könnte, aber vielleicht ist mir schon jemand zuvorgekommen.

    • Nach den in den Geschwisterkommentaren erwähnten API-Enumerationsmethoden muss man wohl gar nicht schätzen.
      https://docs.gitlab.com/api/projects/#list-all-projects — aus irgendeinem merkwürdigen Grund nennt GitLab sie offenbar Projekte statt Repositorys.
      https://codeberg.org/api/swagger#/repository/repoGetByID — da es von der Forgejo.org-Seite verlinkt ist, gilt das vermutlich sowohl für Forgejo als auch für Codeberg.
      Und dessen Freund https://gitea.com/api/swagger#/repository/repoGetByID
      Heptapod ist ein „freundlicher Fork“ von GitLab CE, daher funktioniert die API genauso: https://heptapod.net/pages/faq#api-hgrc
      Danach müsste man wohl projektspezifische GitLab-Instanzen indexieren: Gnome, GNU (falls sie irgendwann wieder öffnen), die Lage bei Savannah, wahrscheinlich Sourceforge, vielleicht sogar sourcehut.
      Wenn ich im Lotto gewinne, würde ich gern den Betrieb von sourcegraph-Instanzen aus der Zeit finanzieren, als es noch unter der Apache-Lizenz stand, und zwar über möglichst viele Orte hinweg, und diese Snapshots dem Internet Archive spenden.
    • Software Heritage hat 380 Millionen öffentliche Repositorys katalogisiert, davon 280 Millionen auf GitHub: https://archive.softwareheritage.org/
      Die Repository-Suche ist noch ziemlich eingeschränkt; sie erlaubt im Wesentlichen nur Volltextsuchen in URLs oder die Suche in einigen wenigen Metadatendateien wie package.json.

  • https://ohshitgit.com