2 points par GN⁺ 2025-06-12 | 1 commentaires | Partager sur WhatsApp
  • L’utilisateur GitHub jonmagic a célébré dans l’issue #1 la création du milliardième dépôt de GitHub, en indiquant que le dépôt shit possédait cet ID
  • La réponse curl -s présentée comme preuve contient l’id 1000000000, le node_id R_kgDOOO5rKAA, le name shit et le full_name AasishPokhrel/shit
  • Le fil de commentaires s’est poursuivi principalement autour de félicitations et de blagues utilisant le nom du dépôt et l’emoji 💩, et le message initial a reçu des milliers de réactions 👍·😄·🎉
  • jonmagic a laissé des liens vers la documentation GitHub, en indiquant que le propriétaire du dépôt pouvait, si nécessaire, verrouiller la conversation ou se désabonner
  • Le 28 juin 2025, le propriétaire du dépôt a limité la conversation aux collaborateurs et l’a verrouillée ; le même jour, un commentaire a été supprimé

shit, désigné comme le milliardième dépôt

  • Le titre de l’issue est Congratulations on creating the one billionth repository on GitHub! et son contenu félicite la création du milliardième dépôt sur GitHub
  • jonmagic félicite le créateur du dépôt et présente comme preuve une partie du résultat de l’appel API suivant
  • Le message de félicitations inclut une blague jouant sur le nom du dépôt, du type « j’espère que vous aurez l’occasion de créer quelque chose de 💩 formidable »

Réactions dans les commentaires et enchaînement de blagues

  • Les premiers commentaires sont principalement composés de félicitations et de jeux de mots
    • « J’ai hâte de voir quelle formidable 💩 vous allez créer »
    • « Je suis impatient de voir cette 💩 décoller »
    • « Je vais fork ça »
    • « Je laisse un commentaire avant que cette issue soit verrouillée »
  • MangoCubes a réagi en disant être rassuré que jonmagic soit un employé de GitHub
  • jordigh a parodié le format habituel des commentaires d’issue, en demandant s’il existait une « estimation de date de correction ou une solution de contournement »
  • Par la suite, de courts commentaires comme 💩, sssssssshit ou « peak shit » ont continué à apparaître

Indications face à l’afflux de notifications

Ampleur de la participation et réactions

  • Le corps de l’issue d’origine affiche des milliers de réactions
    • 👍 4524
    • 😄 2116
    • 🎉 2638
    • ❤️ 945
    • 🚀 1201
    • 👀 611
  • Au milieu de la liste des commentaires, l’interface indique qu’il reste 1136 éléments supplémentaires, ce qui signifie que seuls certains commentaires sont affichés
  • Les métadonnées affichent une partie des participants ainsi que +1092

Verrouillage et état ultérieur

  • Le 28 juin 2025, le propriétaire du dépôt a verrouillé la conversation et l’a limitée aux collaborateurs
  • Le même jour, un commentaire de luckydonald a été supprimé
  • En bas de l’issue, GitHub indique qu’il faut s’inscrire ou se connecter pour participer à la conversation

1 commentaires

 
GN⁺ 2025-06-12
Avis de Hacker News
  • Cela me rappelle le 100 millionième changeset d’OpenStreetMap
    Quelques personnes, moi compris, avaient essayé de le viser gentiment, mais au final il est revenu non pas à quelqu’un qui le convoitait, mais à une personne qui cartographiait activement l’Afrique
    Avec le recul, c’était une fin bien plus chaleureuse, et cette personne avait même déjà été proposée comme candidate pour un prix OSM
    Dans OpenStreetMap, tout est de la vraie donnée de production, donc il est difficile de créer vite fait des données poubelles ; du coup, il semble plus probable que le N-ième commit corresponde au travail spontané de quelqu’un
    C’est aussi une réussite amusante pour GitHub :)
    Pour en savoir plus sur ce jalon OSM, voici le billet officiel du blog : https://blog.openstreetmap.org/2021/02/25/100-million-edits-...
    Mon récapitulatif de l’activité des changesets à l’époque : https://www.openstreetmap.org/user/LucGommans/diary/395954

    • Il y a longtemps, un ami a passé toute une journée de travail à essayer de créer le millionième ticket de notre helpdesk
      Je ne sais plus comment il a fini par y arriver, mais l’équipe a même organisé une petite fête pour célébrer cet accomplissement
      C’était probablement il y a environ 15 ans ; à l’époque, j’ai l’impression que travailler dans la tech était plus amusant
  • Génial ! Dans le OpenAPI Spec interne de GitHub, il ne reste aussi qu’un peu plus d’un milliard de dépôts avant de dépasser int32
    C’est déjà en train d’arriver pour les ID d’exécution de workflows
    https://github.com/github/rest-api-description/issues/4511

    • Dans une entreprise où j’ai brièvement travaillé comme CTO, une table centrale comptait déjà 1,3 milliard de lignes et utilisait un entier 32 bits comme clé primaire
      Au rythme de croissance de l’époque, la valeur de la clé primaire allait déborder en quelques mois ; nous avons donc mené assez urgemment un projet pour passer les ID en 64 bits afin d’éviter une catastrophe
    • Il y a quelques semaines, LuaRocks a dépassé les 65 535 packages, ce qui a posé quelques problèmes à la communauté Lua
      Ce nombre entrait en conflit avec l’implémentation de LuaRocks sous LuaJIT [1] [2], et a fait échouer les pipelines CI/CD et les workflows personnels de certains utilisateurs, ce qui a été pénible
      Le problème a été résolu assez vite, mais c’était intéressant
      [1] https://github.com/luarocks/luarocks/issues/1797
      [2] https://github.com/openresty/docker-openresty/issues/276
  • J’aurais aimé être encore chez Apple
    La plupart des gens ici savent sans doute qu’Apple utilise depuis très longtemps un outil interne appelé Radar
    Chaque Radar a un ID, autrement dit un numéro de bug
    Les Radar du genre bug #1 000 000 étaient assez spéciaux
    Sauf si quelqu’un faisait une erreur et décevait toute l’équipe, c’était généralement de faux Radar remplis de blagues internes
    Il suffisait d’en ouvrir un pour s’amuser, car Radar pouvait référencer d’autres Radar ; en général, on tombait alors dans un rabbit hole réjouissant
    C’était vraiment idiot de ma part de ne pas en avoir capturé ou imprimé quelques-uns quand j’en avais l’occasion

    • Le système de gestion de versions du monorepo de Google attribue lui aussi un ID croissant monotone à chaque changement
      Malheureusement, il y a quelques années, à l’approche d’un certain nombre rond, des gens ont lancé des scripts pour essayer d’obtenir cet ID, ce qui a mis le système en état de déni de service
      Donc maintenant, les ID proches des gros nombres ronds sont sautés :(
      Il y a probablement là une leçon à tirer sur la conception de schémas
    • À l’inverse, quand on pense à la manière dont Apple traite les données confidentielles, je n’aurais pas eu envie de me faire prendre à sortir des documents internes, aussi inoffensifs qu’ils puissent paraître
  • Tant qu’on parle des ID de dépôts GitHub, le tout premier dépôt est ici
    https://api.github.com/repositories/1
    https://github.com/mojombo/grit

  • Il a probablement vérifié en boucle avec un script https://api.github.com/repositories/999999999, puis créé un nouveau dépôt dès qu’il est apparu
    Comme les dépôts peuvent être modifiés, il a aussi pu en créer plusieurs avec de la marge, puis supprimer ceux qui n’avaient pas le bon numéro
    À voir les autres dépôts créés hier par l’auteur, “yep” devait être le nombre magique, et “shit” l’aveu que c’était raté
    Quelqu’un se souvient de D666666 chez Facebook ?
    C’était une énorme transformation de code, et son auteur avait utilisé une technique similaire pour obtenir ce numéro précis

    • Ou peut-être pas
      Je ne vois pas pourquoi on suppose que cette personne a délibérément cherché à obtenir ce dépôt
    • Comme c’est un dépôt vide, ça semble bien être le cas
  • Sérieusement, je suis un peu surpris que GitHub ait rendu le calcul du rythme de création de nouveaux dépôts aussi facile
    Ce genre d’information n’est-il pas normalement un secret d’entreprise ?

    • Quand votre douve fait un milliard de large, j’imagine qu’on peut se permettre de se balader un peu en sous-vêtements
    • GitHub a-t-il une raison de cacher cette information ?
      Je ne vois pas comment on pourrait l’utiliser au détriment de GitHub
      Je comprends que beaucoup d’entreprises aient pour position par défaut de ne rien divulguer tant qu’elles n’y sont pas obligées
    • Avec une recherche binaire, on peut aussi trouver le dernier ID très rapidement
      J’ai déjà suivi la croissance de plusieurs sites web de cette façon
    • On peut aussi voir le rythme de création de nouveaux utilisateurs
      D’une certaine manière, c’est encore plus intéressant
  • Je me demande si AasishPokhrel a créé ce dépôt pour devenir le milliardième dépôt

    • AasishPokhrel a créé deux dépôts hier, « shit » et « yep »
      Il n’y a eu aucune activité entre le 17 mai et le 10 juin
      Je ne sais pas s’il est possible de calculer le rythme de création des dépôts et d’en créer un au bon moment pour obtenir le numéro voulu
    • C’est assez facile à manipuler
      Il suffit de continuer à créer des dépôts jusqu’à ce que le milliardième apparaisse, puis de supprimer les précédents
      Avec l’API GitHub, c’est très simple
      Les seuls problèmes sont les limites de débit et les autres personnes qui créent des dépôts en même temps, donc au final c’est une question de chance
    • Il semble être un étudiant népalais en développement logiciel, et je trouve vraiment émouvant qu’un jalon comme celui-ci puisse atteindre des endroits si éloignés du monde
      J’espère qu’il le mettra bien en avant sur son CV et trouvera une belle carrière dans le développement
    • C’est très suspect, mais ça semble possible
  • Le dépôt a été renommé et semble maintenant rediriger vers https://github.com/AasishPokhrel/repository/
    Pas terrible :-(

    • Il a repris son nom d’origine ! :-D
  • Je me demande combien de dépôts il y aurait au total si l’on incluait tous les serveurs Forgejo et GitLab locaux
    Sans oublier Subversion, Mercurial, les autres amis de git, et ses ennemis
    Quelqu’un a-t-il déjà créé un moteur de recherche pour tout ça ?
    Ce serait bien de pouvoir rechercher un mot comme « a » pour estimer approximativement l’ampleur
    Le grand avantage d’un GitHub centralisé m’a toujours semblé être que les gens peuvent réellement trouver mon code
    Après le rachat de GitHub par Microsoft, j’ai pensé à créer un moteur de recherche, mais j’ai fini par ne pas le faire parce que je ne pensais pas pouvoir gérer le marketing et que cela aurait été vain
    Récemment, en mettant plusieurs projets sur Codeberg, je me suis demandé si cela valait la peine de retenter, mais quelqu’un m’a peut-être déjà devancé

    • À en juger par les méthodes d’énumération via API mentionnées dans les commentaires voisins, il n’est sans doute pas nécessaire d’estimer
      https://docs.gitlab.com/api/projects/#list-all-projects — pour une raison étrange, GitLab semble appeler ça des projets plutôt que des dépôts
      https://codeberg.org/api/swagger#/repository/repoGetByID — comme c’est lié depuis le site Forgejo.org, c’est probablement le même pour Forgejo et Codeberg
      Et son camarade https://gitea.com/api/swagger#/repository/repoGetByID
      Heptapod est un « fork convivial » de GitLab CE, donc l’API fonctionne de la même manière : https://heptapod.net/pages/faq#api-hgrc
      Ensuite, il faudrait sans doute indexer les instances GitLab propres à chaque projet : Gnome, GNU (s’ils la rouvrent un jour), la situation du côté de Savannah, probablement Sourceforge, peut-être même sourcehut
      Si je gagne à la loterie, j’aimerais financer l’exploitation d’instances de sourcegraph de l’époque où c’était sous licence Apache sur autant de sites que possible, puis donner ces instantanés à l’Internet Archive
    • Software Heritage a répertorié 380 millions de dépôts publics, dont 280 millions sur GitHub : https://archive.softwareheritage.org/
      La recherche de dépôts est encore assez limitée : elle se résume à une recherche plein texte sur l’URL ou à quelques fichiers de métadonnées comme package.json
  • https://ohshitgit.com