2 poin oleh GN⁺ 2025-06-12 | 1 komentar | Bagikan ke WhatsApp
  • Pengguna GitHub jonmagic merayakan pembuatan repositori ke-1 miliar GitHub di Issue #1, sambil memberi tahu bahwa repositori shit memiliki ID tersebut
  • Sebagai bukti, respons curl -s yang ditunjukkan mencakup id 1000000000, node_id R_kgDOOO5rKAA, name shit, dan full_name AasishPokhrel/shit
  • Alur komentar kemudian berlanjut terutama dengan ucapan selamat dan candaan yang memanfaatkan nama repositori serta emoji 💩, dan postingan awal menerima ribuan reaksi 👍·😄·🎉
  • jonmagic meninggalkan tautan dokumentasi GitHub sambil menyebut bahwa pemilik repositori dapat menggunakan penguncian percakapan atau berhenti berlangganan jika diperlukan
  • Pada 28 Juni 2025, pemilik repositori membatasi percakapan hanya untuk collaborator lalu menguncinya, dan satu komentar juga dihapus pada hari yang sama

shit yang disebut sebagai repositori ke-1 miliar

  • Judul issue adalah Congratulations on creating the one billionth repository on GitHub!, berisi ucapan selamat atas pembuatan repositori ke-1 miliar di GitHub
  • jonmagic mengucapkan selamat kepada pembuat repositori sambil menunjukkan sebagian hasil pemanggilan API berikut sebagai dasar
  • Pesan selamat itu juga memuat candaan yang memanfaatkan nama repositori, seperti “semoga ada kesempatan untuk membuat 💩 yang keren”

Reaksi komentar dan alur candaan

  • Komentar-komentar awal sebagian besar berisi ucapan selamat dan permainan kata
    • “Penasaran akan jadi 💩 keren seperti apa”
    • “Tak sabar menunggu 💩 ini meledak”
    • “Saya akan fork ini”
    • “Saya meninggalkan komentar sebelum issue ini dikunci”
  • MangoCubes meninggalkan reaksi bahwa ia lega karena jonmagic adalah karyawan GitHub
  • jordigh memparodikan format komentar issue pada umumnya dengan gaya seperti, “apakah ada perkiraan jadwal perbaikan atau solusi sementara?”
  • Setelah itu, komentar-komentar pendek seperti 💩, sssssssshit, dan “peak shit” terus bermunculan

Panduan terkait banjir notifikasi

Skala partisipasi dan reaksi

  • Di isi issue asli, terlihat ribuan reaksi
    • 👍 4524
    • 😄 2116
    • 🎉 2638
    • ❤️ 945
    • 🚀 1201
    • 👀 611
  • Di tengah daftar komentar ada penanda masih ada 1136 item lagi, yang menunjukkan hanya sebagian komentar yang sedang ditampilkan
  • Di metadata, terlihat sebagian peserta bersama +1092

Penguncian dan status setelahnya

  • Pada 28 Juni 2025, pemilik repositori mengunci percakapan dan membatasinya untuk collaborator
  • Pada hari yang sama, satu komentar dari luckydonald dihapus
  • Di bagian bawah issue, ditampilkan panduan bahwa untuk berpartisipasi dalam percakapan GitHub, pengguna harus mendaftar atau masuk

1 komentar

 
GN⁺ 2025-06-12
Komentar Hacker News
  • Ini mengingatkan pada changeset ke-100 juta OpenStreetMap
    Beberapa orang, termasuk saya, sempat mengincarnya santai, tetapi akhirnya jatuh bukan ke orang yang mengincarnya, melainkan ke orang yang sedang rajin memetakan Afrika
    Kalau dipikir-pikir, itu akhir yang jauh lebih menghangatkan hati, dan orang itu sebelumnya juga pernah dinominasikan sebagai kandidat penghargaan OSM
    Di OpenStreetMap semuanya adalah data operasional nyata, jadi sulit membuat data sampah sembarangan; karena itu, sepertinya lebih besar kemungkinan commit ke-N adalah hasil kerja spontan seseorang
    Ini juga pencapaian yang menarik untuk GitHub :)
    Kalau ingin membaca lebih lanjut tentang tonggak OSM, ini tulisan blog resminya: https://blog.openstreetmap.org/2021/02/25/100-million-edits-...
    Ringkasan saya tentang aktivitas changeset saat itu: https://www.openstreetmap.org/user/LucGommans/diary/395954

    • Dulu seorang teman menghabiskan satu hari kerja penuh untuk membuat tiket ke-1 juta di helpdesk kami
      Saya tidak tahu bagaimana akhirnya ia berhasil, tetapi tim bahkan mengadakan pesta kecil untuk memperingati pencapaian itu
      Mungkin sekitar 15 tahun lalu, dan rasanya pekerjaan di industri teknologi waktu itu lebih menyenangkan
  • Keren! OpenAPI Spec milik GitHub sendiri juga sekarang tinggal sedikit di atas 1 miliar repositori lagi sebelum int32 meluap
    Pada ID eksekusi workflow, itu sudah terjadi
    https://github.com/github/rest-api-description/issues/4511

    • Ketika saya masuk ke sebuah perusahaan tempat saya sempat menjadi CTO, saya mendapati salah satu tabel intinya sudah memiliki 1,3 miliar baris, tetapi masih memakai integer 32-bit sebagai primary key
      Dengan laju pertumbuhan saat itu, nilai primary key akan meluap dalam beberapa bulan, jadi kami cukup tergesa-gesa menjalankan proyek untuk menaikkan ID ke 64-bit demi menghindari bencana besar
    • Beberapa minggu lalu, ketika LuaRocks melewati 65.535 paket, komunitas Lua mengalami sedikit masalah
      Angka ini bertabrakan dengan implementasi LuaRocks di LuaJIT [1] [2], membuat pipeline CI/CD dan alur kerja pribadi sebagian pengguna gagal dan cukup menyakitkan
      Masalahnya diselesaikan cukup cepat, tetapi itu kejadian yang menarik
      [1] https://github.com/luarocks/luarocks/issues/1797
      [2] https://github.com/openresty/docker-openresty/issues/276
  • Andai saya masih di Apple
    Kebanyakan orang di sini mungkin tahu bahwa Apple sudah lama memakai tool internal bernama Radar
    Setiap Radar diberi ID, yaitu nomor bug
    Radar seperti bug #1.000.000 terasa cukup spesial
    Kecuali ada orang yang keliru dan mengecewakan seluruh tim, biasanya itu Radar palsu yang penuh lelucon internal
    Membuka satu saja sudah cukup, karena Radar bisa merujuk ke Radar lain, jadi biasanya dari situ kita masuk ke rabbit hole dan menikmatinya
    Bodoh sekali saya tidak sempat menangkap layar atau mencetak beberapa di antaranya ketika ada kesempatan

    • Sistem version control monorepo Google juga memberi ID meningkat monoton seperti ini pada setiap perubahan
      Sayangnya, beberapa tahun lalu ketika mendekati sebuah angka bulat, orang-orang yang ingin mendapatkan ID itu menjalankan skrip hingga sistem mengalami denial of service
      Jadi sekarang ID di sekitar angka bulat besar dilewati :(
      Mungkin ada pelajaran soal desain skema di sini
    • Sebaliknya, mengingat cara Apple menangani data rahasia, rasanya saya tidak ingin tertangkap membawa keluar dokumen internal, semeskipun tampaknya tidak berbahaya
  • Mumpung membahas ID repositori GitHub, repositori pertama ada di sini
    https://api.github.com/repositories/1
    https://github.com/mojombo/grit

  • Mungkin ia berulang kali mengecek https://api.github.com/repositories/999999999 dengan skrip, lalu membuat repositori baru begitu muncul
    Karena repositori bisa diubah, ia juga mungkin membuat beberapa dengan jarak aman lalu menghapus yang nomornya tidak cocok
    Melihat repositori lain yang dibuat penulis kemarin, sepertinya “yep” adalah angka ajaibnya, dan “shit” adalah pengakuan bahwa itu meleset
    Ada yang ingat D666666 milik Facebook?
    Itu transformasi kode besar-besaran, dan penulisnya memakai teknik yang mirip untuk mendapatkan nomor tertentu

    • Atau mungkin juga tidak
      Saya tidak tahu kenapa orang mengasumsikan orang ini sengaja mendapatkan repositori itu
    • Karena repositorinya kosong, sepertinya memang begitu
  • Serius, agak mengejutkan bahwa GitHub membuat perhitungan laju pembuatan repositori baru semudah ini
    Bukankah informasi seperti ini biasanya rahasia perusahaan?

    • Kalau parit pertahanannya selebar 1 miliar, rasanya orang jadi bisa agak berkeliaran dengan hanya memakai pakaian dalam
    • Apakah ada alasan bagi GitHub untuk menyembunyikan informasi ini?
      Saya tidak tahu bagaimana ini bisa dipakai untuk merugikan GitHub
      Saya paham banyak perusahaan menjadikan “tidak mengungkapkan apa pun kecuali dipaksa” sebagai default
    • Dengan binary search, ID terbaru juga bisa ditemukan sangat cepat
      Dulu saya melacak pertumbuhan beberapa situs web dengan cara seperti ini
    • Laju pembuatan pengguna baru juga bisa dilihat
      Dalam beberapa hal, yang itu lebih menarik
  • Saya penasaran apakah AasishPokhrel membuat repositori ini supaya menjadi repositori ke-1 miliar

    • AasishPokhrel kemarin membuat 2 repositori, “shit” dan “yep”
      Tidak ada aktivitas antara 17 Mei dan 10 Juni
      Saya tidak tahu apakah laju pembuatan repositori bisa dihitung lalu membuat repositori agar pas dengan nomor yang diinginkan
    • Ini cukup mudah dimanipulasi
      Tinggal terus membuat repositori sampai yang ke-1 miliar muncul, lalu hapus yang sebelumnya
      Dengan GitHub API, ini sangat sederhana
      Masalahnya hanya rate limit dan orang lain yang membuat repositori pada saat yang sama, jadi pada akhirnya soal keberuntungan
    • Sepertinya dia mahasiswa yang belajar pengembangan perangkat lunak di Nepal, dan sungguh mengharukan bahwa tonggak seperti ini bisa menjangkau begitu jauh ke berbagai penjuru dunia
      Semoga dia mencantumkannya besar-besar di CV dan menemukan karier yang bagus di bidang pengembangan
    • Sangat mencurigakan, tapi tampaknya memang mungkin
  • Repositori itu namanya sudah diubah dan sekarang tampaknya dialihkan ke https://github.com/AasishPokhrel/repository/
    Kurang oke :-(

    • Sudah berubah kembali ke nama aslinya! :-D
  • Saya penasaran berapa total repositori jika server Forgejo lokal dan GitLab juga dihitung
    Termasuk Subversion, Mercurial, teman-teman git yang lain, bahkan para musuhnya juga
    Apakah sudah ada yang membuat mesin pencari untuk hal-hal seperti ini?
    Akan bagus kalau bisa memperkirakan skalanya dengan mencari kata seperti “a”
    Keuntungan besar GitHub yang tersentralisasi tampaknya selalu bahwa orang benar-benar bisa menemukan kode saya
    Setelah Microsoft mengakuisisi GitHub, saya sempat berpikir untuk membuat pencarian seperti itu, tapi akhirnya tidak jadi karena rasanya akan sia-sia karena saya tidak mampu menangani sisi pemasarannya
    Belakangan, setelah mengunggah beberapa proyek ke Codeberg, saya kembali berpikir apakah ini layak dicoba, tapi mungkin seseorang sudah mendahului

    • Melihat metode enumerasi API yang disebut di komentar-komentar saudara, sepertinya tidak perlu memperkirakan
      https://docs.gitlab.com/api/projects/#list-all-projects — entah karena alasan aneh, GitLab tampaknya menyebutnya project, bukan repositori
      https://codeberg.org/api/swagger#/repository/repoGetByID — ini ditautkan dari situs Forgejo.org, jadi mungkin sama untuk Forgejo dan Codeberg
      Dan temannya itu https://gitea.com/api/swagger#/repository/repoGetByID
      Heptapod adalah “fork ramah” dari GitLab CE, jadi API-nya juga bekerja sama: https://heptapod.net/pages/faq#api-hgrc
      Berikutnya mungkin perlu mengindeks instance GitLab per proyek: Gnome, GNU (kalau suatu hari dibuka lagi), situasi di Savannah, mungkin Sourceforge, bahkan mungkin sourcehut
      Kalau saya menang lotre, saya ingin mendanai pengoperasian instance sourcegraph dari masa ketika masih berlisensi Apache di sebanyak mungkin tempat, lalu menyumbangkan snapshot-nya ke Internet Archive
    • Software Heritage telah mengatalogkan 380 juta repositori publik, dan 280 juta di antaranya ada di GitHub: https://archive.softwareheritage.org/
      Pencarian repositorinya masih cukup terbatas, kurang lebih hanya pencarian teks penuh URL atau pencarian sejumlah kecil file metadata seperti package.json
  • https://ohshitgit.com