GitHubで10億番目のリポジトリ作成を祝福

 (github.com/AasishPokhrel)
2 ポイント 投稿者 GN⁺ 2025-06-12 | 1件のコメント | WhatsAppで共有
  • GitHubユーザーのjonmagicがIssue #1で、GitHubの10億番目のリポジトリ作成を祝福し、リポジトリ shit がそのIDを持つと伝えた
  • 根拠として示された curl -s のレスポンスには、id 1000000000、node_id R_kgDOOO5rKAA、name shit、full_name AasishPokhrel/shit が含まれている
  • コメントの流れは、リポジトリ名と💩絵文字を使った祝福やジョークが中心で、最初の投稿には数千件の 👍・😄・🎉 リアクションが付いた
  • jonmagicは、リポジトリ所有者が必要であれば会話のロックや購読解除を利用できるとして、GitHubドキュメントへのリンクを残した
  • 2025年6月28日、リポジトリ所有者が会話をcollaboratorに制限してロックし、同日コメント1件が削除された

10億番目のリポジトリとされた shit

  • Issueのタイトルは Congratulations on creating the one billionth repository on GitHub! で、GitHubでの10億番目のリポジトリ作成を祝福する内容
  • jonmagicはリポジトリ作成者を祝福しつつ、次のAPI呼び出し結果の一部を根拠として示した
  • 祝福メッセージには、「素晴らしい💩を作る機会があることを願う」といった形で、リポジトリ名を使ったジョークが含まれている

コメントの反応とジョークの流れ

  • 初期のコメントは、ほとんどが祝福とダジャレで構成されている
    • 「どんな素晴らしい💩を作るのか楽しみだ」
    • 「この💩が注目されるのを待ちきれない」
    • 「これをforkする」
    • 「このIssueがロックされる前にコメントを残しておく」
  • MangoCubesは、jonmagicがGitHub社員なので安心したという反応を残した
  • jordighは「修正予定時期や回避策はあるのか」といった、一般的なIssueコメント形式をパロディ化した
  • その後も 💩、sssssssshit、「peak shit」のような短いコメントが続いた

通知の急増に関する案内

参加規模とリアクション

  • 元のIssue本文には、数千件のリアクションが表示されている
    • 👍 4524件
    • 😄 2116件
    • 🎉 2638件
    • ❤️ 945件
    • 🚀 1201件
    • 👀 611件
  • コメント一覧の途中には、さらに1136件の項目が残っていると表示され、一部のコメントだけが表示されている状態
  • メタデータには参加者の一部と +1092 が表示されている

ロックとその後の状態

  • 2025年6月28日、リポジトリ所有者が会話をロックし、collaboratorに制限した
  • 同日、luckydonald のコメント1件が削除された
  • Issue下部には、GitHubの会話に参加するには登録またはログインが必要だという案内が表示されている

関連記事

1件のコメント

 
GN⁺ 2025-06-12
Hacker News の意見

  • OpenStreetMapの1億番目の変更セットを思い出した
    自分を含め何人かが軽い気持ちで狙っていたけれど、結局は狙っていた人ではなく、アフリカの地図を熱心に描いていた人のものになった
    振り返るとずっと心温まる結末で、その人は以前OSM賞の候補にも推薦されたことがあった
    OpenStreetMapはすべてが実運用データなので、適当なゴミデータを作るのは難しく、だからN番目のコミットが誰かの思いつき作業になる可能性のほうが高いように思う
    GitHubにとっても面白い偉業だね :)
    OSMのマイルストーンについてもっと読みたいなら公式ブログ記事: https://blog.openstreetmap.org/2021/02/25/100-million-edits-...
    当時の変更セット活動についての自分のまとめ: https://www.openstreetmap.org/user/LucGommans/diary/395954

    • 昔、友人がうちのヘルプデスク100万番目のチケットを作ろうとして、勤務日を丸一日費やしていた
      結局どうやって達成したのかは知らないけれど、その偉業を記念してチームで小さなパーティーも開いた
      たぶん15年くらい前で、あの頃はテック業界の仕事がもっと面白かった気がする

  • すごい！GitHub自身のOpenAPI Specでも、リポジトリ数がint32をオーバーフローするまで、あと10億個ちょっとしか残っていない
    ワークフロー実行IDではすでにそれが起きている
    https://github.com/github/rest-api-description/issues/4511

    • CTOとして短期間働いていた会社に行ってみたら、重要なテーブルの1つがすでに13億行あり、主キーに32ビット整数を使っていた
      当時の増加ペースだと数か月以内に主キーの値があふれる状況だったので、大惨事を避けるためにIDを64ビットへ上げるプロジェクトをかなり急いで進めた
    • 数週間前、LuaRocksが65,535個のパッケージを超えたことで、Luaコミュニティに少し問題が起きた
      この数字とLuaJITにおけるLuaRocksの実装が衝突し [1] [2]、一部ユーザーのCI/CDパイプラインや個人の作業フローが失敗して苦しめられた
      かなり早く解決されたが、興味深い出来事だった
      [1] https://github.com/luarocks/luarocks/issues/1797
      [2] https://github.com/openresty/docker-openresty/issues/276

  • まだAppleにいたらよかったのに
    ここにいる大半の人は、Appleが昔からRadarという社内ツールを使っていることを知っていると思う
    各RadarにはID、つまりバグ番号が付いている
    バグ#1,000,000のようなRadarはかなり特別だった
    誰かがミスをしてチーム全体をがっかりさせない限り、たいていは内輪ネタがたっぷり入った偽のRadarだった
    1つ開くだけでも十分だったが、Radarは別のRadarを参照できたので、だいたいそこからrabbit holeにはまり込んで楽しむことになった
    機会があったときにいくつかでもキャプチャしたり印刷したりしておかなかったのは、本当に愚かだった

    • Googleのモノレポ版管理システムにも、変更ごとにこのような単調増加IDが付く
      残念ながら数年前、あるキリのいい数字に近づいたとき、そのIDを取ろうとする人たちがスクリプトを回して、システムがサービス拒否状態になった
      そのため今では、大きなキリ番の近くのIDはスキップされる :(
      ここにはおそらくスキーマ設計に関する教訓があるのだろう
    • 逆にAppleが機密データを扱う方法を考えると、どれほど無害に見えても社内文書を持ち出して見つかりたくはなかっただろう

  • GitHubのリポジトリIDの話をするなら、最初のリポジトリはここにある
    https://api.github.com/repositories/1
    https://github.com/mojombo/grit

  • おそらくスクリプトで https://api.github.com/repositories/999999999 を繰り返し確認し、現れた瞬間に新しいリポジトリを作ったのだろう
    リポジトリは編集できるので、余裕を持って複数作ったあと、目的の番号でないものを削除したのかもしれない
    作者が昨日作った別のリポジトリを見ると、“yep”が魔法の数字で、“shit”は外したことを認めるものだったように思える
    FacebookのD666666を覚えている人はいる？
    巨大なコード変換で、作者は特定の番号を得るためにこれと似た手法を使っていた

    • あるいは違うかもしれない
      なぜこの人がわざとそのリポジトリを取ったと仮定するのか分からない
    • 空のリポジトリなので、そうっぽい

  • 真面目に言うと、GitHub が新規リポジトリの作成速度をこんなに簡単に計算できるようにしているのは少し驚き
    こういう情報って普通は企業秘密じゃないの？

    • 堀が10億個分の幅もあれば、下着姿で多少うろつくことになるんだと思う
    • GitHub がこの情報を隠すべき理由はあるのかな？
      これをどうやって GitHub に不利に使えるのか分からない
      多くの企業が、強制されない限り何も情報を公開しないことをデフォルトにしているのは理解できる
    • 二分探索を使えば最新の ID もものすごく速く見つけられる
      以前、いくつもの Web サイトの成長をこうやって追跡していた
    • 新規ユーザーの作成速度も見られる
      ある意味ではそちらのほうが興味深い

  • AasishPokhrel が10億番目のリポジトリになるためにこのリポジトリを作ったのか気になる

    • AasishPokhrel は昨日、「shit」と「yep」という2つのリポジトリを作っていた
      5月17日から6月10日の間は活動がなかった
      リポジトリ作成速度を計算して、狙った番号に合わせてリポジトリを作れるのかは分からない
    • これはかなり簡単に操作できる
      10億番目が出るまでリポジトリを作り続けて、前のものを削除すればいい
      GitHub API ならとても簡単
      問題はレート制限と、同時にリポジトリを作っている他の人たちだけなので、結局は運の問題
    • 彼はネパールでソフトウェア開発を学んでいる大学生のようだけど、こういう節目が世界の奥深くまで届きうるというのは本当に胸に来る
      これを履歴書に大きく載せて、開発分野でよいキャリアを見つけてほしい
    • かなり怪しいけれど、可能ではありそう

  • そのリポジトリは名前が変わって、今は https://github.com/AasishPokhrel/repository/ にリダイレクトされるようだ
    いまいち :-(

    • また元の名前に戻った！ :-D

  • ローカルの Forgejo や GitLab サーバーまで全部合わせると、リポジトリ全体でどれくらいあるのか気になる
    Subversion、Mercurial、git の他の友人たち、そして敵たちまで含めての話
    こういうもののための検索エンジンを、もう誰か作っているのだろうか？
    「a」みたいな単語を検索して、おおよその規模を推定できるとよさそう
    中央集権的な GitHub の大きな利点は、常に人々が実際に自分のコードを見つけられることのように見えていた
    Microsoft が GitHub を買収してから検索を作ってみようかと考えたけれど、マーケティング方面をさばけなくて無駄骨になりそうだったので結局やらなかった
    最近は Codeberg に複数のプロジェクトを置いていて、もう一度やる価値があるかもと考えたが、誰かがすでに先を越しているかもしれない

    • 兄弟コメントで出ている API 列挙の方法を見ると、わざわざ推定する必要はなさそう
      https://docs.gitlab.com/api/projects/#list-all-projects — 奇妙な理由で GitLab はリポジトリではなくプロジェクトと呼んでいるようだ
      https://codeberg.org/api/swagger#/repository/repoGetByID — Forgejo.org サイトからリンクされているものなので、おそらく Forgejo と Codeberg の両方で同じはず
      それからその仲間 https://gitea.com/api/swagger#/repository/repoGetByID
      Heptapod は GitLab CE の「友好的なフォーク」なので API も同じように動作する: https://heptapod.net/pages/faq#api-hgrc
      次はプロジェクト別の GitLab インスタンスをインデックスする必要がありそう: Gnome、GNU（いつか再開してくれるなら）、Savannah 周辺の状況、おそらく Sourceforge、ひょっとすると sourcehut まで
      宝くじに当たったら、Apache ライセンスだった頃の sourcegraph インスタンスをできるだけ多くの場所にまたがって運用する資金を出し、そのスナップショットを Internet Archive に寄付したい
    • Software Heritage では公開リポジトリ3億8,000万個をカタログ化しており、そのうち2億8,000万個が GitHub にある: https://archive.softwareheritage.org/
      リポジトリ検索はまだかなり限定的で、URL の全文検索や package.json のような少数のメタデータファイル検索くらいしかできない

  • https://ohshitgit.com