ร่วมฉลองการสร้างรีโพซิทอรีลำดับที่ 1 พันล้านบน GitHub

 (github.com/AasishPokhrel)
2 คะแนน โดย GN⁺ 2025-06-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผู้ใช้ GitHub ชื่อ jonmagic โพสต์ใน Issue #1 เพื่อแสดงความยินดีกับการสร้าง รีโพซิทอรีลำดับที่ 1 พันล้านของ GitHub และระบุว่ารีโพซิทอรี shit คือรีโพซิทอรีที่มี ID ดังกล่าว
  • หลักฐานที่ยกมาคือผลลัพธ์จาก curl -s ซึ่งมี id 1000000000, node_id R_kgDOOO5rKAA, name shit, full_name AasishPokhrel/shit รวมอยู่ด้วย
  • กระแสคอมเมนต์ดำเนินไปในแนวร่วมแสดงความยินดีและเล่นมุกจากชื่อรีโพซิทอรีกับอีโมจิ 💩 โดยโพสต์แรกมี รีแอ็กชัน 👍·😄·🎉 หลายพันครั้ง
  • jonmagic ทิ้งลิงก์เอกสารของ GitHub ไว้ พร้อมบอกว่าเจ้าของรีโพซิทอรีสามารถใช้ การล็อกบทสนทนา หรือยกเลิกการติดตามได้หากจำเป็น
  • วันที่ 28 มิถุนายน 2025 เจ้าของรีโพซิทอรีได้ จำกัดบทสนทนาไว้เฉพาะ collaborator และล็อกไว้ และในวันเดียวกันมีคอมเมนต์หนึ่งรายการถูกลบ

shit ที่ถูกชี้ว่าเป็นรีโพซิทอรีลำดับที่ 1 พันล้าน

  • ชื่อ Issue คือ Congratulations on creating the one billionth repository on GitHub! และเป็นข้อความแสดงความยินดีกับการสร้าง รีโพซิทอรีลำดับที่ 1 พันล้าน บน GitHub
  • jonmagic แสดงความยินดีกับผู้สร้างรีโพซิทอรี พร้อมยกผลลัพธ์บางส่วนจากการเรียก API ต่อไปนี้เป็นหลักฐาน
  • ข้อความแสดงความยินดีมีมุกเล่นกับชื่อรีโพซิทอรีในทำนองว่า “หวังว่าจะได้มีโอกาสสร้าง 💩 เจ๋ง ๆ”

ปฏิกิริยาในคอมเมนต์และกระแสมุกตลก

  • คอมเมนต์ช่วงแรกส่วนใหญ่เป็น การแสดงความยินดีและเล่นคำ
    • “ตั้งตารอดูว่าจะสร้าง 💩 เจ๋ง ๆ อะไรออกมา”
    • “แทบรอไม่ไหวให้ 💩 นี้ดังขึ้นมา”
    • “ฉันจะ fork อันนี้”
    • “ขอคอมเมนต์ไว้ก่อนที่ Issue นี้จะถูกล็อก”
  • MangoCubes บอกว่ารู้สึกสบายใจที่ jonmagic เป็นพนักงาน GitHub
  • jordigh ล้อรูปแบบคอมเมนต์ Issue ทั่วไปด้วยข้อความประมาณว่า “มี ETA สำหรับการแก้ไขหรือมีวิธีเลี่ยงไหม”
  • หลังจากนั้นก็ยังมีคอมเมนต์สั้น ๆ ตามมาอย่าง 💩, sssssssshit, และ “peak shit”

คำแนะนำเรื่องการแจ้งเตือนถล่ม

  • jonmagic แนะนำ AasishPokhrel ว่าหากจำเป็นสามารถ ล็อกบทสนทนา หรือยกเลิกการติดตาม ได้
  • ลิงก์เอกสารที่แนบมามีสองรายการดังนี้

ขนาดของการมีส่วนร่วมและปฏิกิริยา

  • ในต้นฉบับของ Issue มีรีแอ็กชันหลายพันรายการแสดงอยู่
    • 👍 4524 ครั้ง
    • 😄 2116 ครั้ง
    • 🎉 2638 ครั้ง
    • ❤️ 945 ครั้ง
    • 🚀 1201 ครั้ง
    • 👀 611 ครั้ง
  • ตรงกลางรายการคอมเมนต์มีข้อความว่า ยังมีอีก 1136 รายการ ทำให้เห็นเพียงบางส่วนของคอมเมนต์ทั้งหมด
  • ในเมทาดาทามีการแสดงผู้เข้าร่วมบางส่วนและ +1092

การล็อกและสถานะหลังจากนั้น

  • วันที่ 28 มิถุนายน 2025 เจ้าของรีโพซิทอรีได้ ล็อกบทสนทนาและจำกัดไว้เฉพาะ collaborator
  • ในวันเดียวกัน คอมเมนต์หนึ่งรายการของ luckydonald ถูกลบ
  • ด้านล่างของ Issue มีข้อความแจ้งว่าหากต้องการเข้าร่วมการสนทนาบน GitHub ต้องสมัครสมาชิกหรือล็อกอินก่อน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-06-12
ความคิดเห็นจาก Hacker News

  • ทำให้นึกถึง changeset ลำดับที่ 100 ล้าน ของ OpenStreetMap
    มีบางคน รวมถึงผมเอง ที่แอบเล็งไว้เล่น ๆ แต่สุดท้ายก็ไม่ได้ตกเป็นของคนที่จ้องไว้ กลับเป็นของคนที่กำลังวาดแผนที่แอฟริกาอย่างขยันขันแข็ง
    พอมองย้อนกลับไปก็เป็นตอนจบที่อบอุ่นใจกว่ามาก และคนคนนั้นเคยถูกเสนอชื่อเข้าชิงรางวัลของ OSM มาก่อนด้วย
    ใน OpenStreetMap ทุกอย่างเป็นข้อมูลที่ใช้งานจริง จึงยากที่จะสร้างข้อมูลขยะส่ง ๆ ขึ้นมา ดังนั้นคอมมิตลำดับที่ N น่าจะมีโอกาสเป็นงานฉับพลันของใครสักคนมากกว่า
    สำหรับ GitHub นี่ก็เป็น achievement ที่น่าสนุกเหมือนกัน :)
    ถ้าอยากอ่านเพิ่มเติมเกี่ยวกับหมุดหมายของ OSM มีบทความบล็อกทางการ: https://blog.openstreetmap.org/2021/02/25/100-million-edits-...
    สรุปของผมเกี่ยวกับกิจกรรม changeset ในตอนนั้น: https://www.openstreetmap.org/user/LucGommans/diary/395954

    • เมื่อก่อนเพื่อนคนหนึ่งใช้เวลาทั้งวันทำงานเพื่อพยายามสร้าง ทิกเก็ต helpdesk ลำดับที่ 1 ล้าน ของพวกเรา
      สุดท้ายไม่รู้ว่าเขาทำสำเร็จได้อย่างไร แต่ทีมก็จัดปาร์ตี้เล็ก ๆ เพื่อฉลอง achievement นั้นด้วย
      น่าจะราว ๆ 15 ปีก่อน ตอนนั้นรู้สึกว่างานในวงการเทคสนุกกว่านี้

  • เจ๋งเลย! OpenAPI Spec ของ GitHub เองก็เหลืออีกแค่พันล้านกว่านิด ๆ เท่านั้นก่อนที่จำนวน repository จะล้น int32
    เรื่องแบบนั้นเกิดขึ้นกับ workflow run ID ไปแล้ว
    https://github.com/github/rest-api-description/issues/4511

    • ตอนผมเข้าไปที่บริษัทแห่งหนึ่งซึ่งเคยทำงานเป็น CTO อยู่ช่วงสั้น ๆ ก็พบว่าตารางหลักตารางหนึ่งมี 1.3 พันล้านแถว ไปแล้ว แต่ยังใช้จำนวนเต็ม 32 บิตเป็น primary key
      ด้วยอัตราการเพิ่มในตอนนั้น ค่า primary key จะล้นภายในไม่กี่เดือน เราจึงต้องเร่งทำโปรเจกต์อัปเกรด ID เป็น 64 บิตเพื่อเลี่ยงหายนะ
    • เมื่อไม่กี่สัปดาห์ก่อน LuaRocks มีแพ็กเกจเกิน 65,535 แพ็กเกจ ทำให้เกิดปัญหาเล็กน้อยในชุมชน Lua
      ตัวเลขนี้ไปชนกับการใช้งาน LuaRocks บน LuaJIT [1] [2] ทำให้ CI/CD pipeline และ workflow ส่วนตัวของผู้ใช้บางส่วนล้มเหลว สร้างความปวดหัวอยู่พักหนึ่ง
      แก้ได้ค่อนข้างเร็ว แต่ก็เป็นเรื่องที่น่าสนใจ
      [1] https://github.com/luarocks/luarocks/issues/1797
      [2] https://github.com/openresty/docker-openresty/issues/276

  • ถ้ายังอยู่ที่ Apple ก็คงดี
    คนส่วนใหญ่ที่นี่น่าจะรู้ว่า Apple ใช้เครื่องมือภายในชื่อ Radar มานานแล้ว
    Radar แต่ละรายการจะมี ID หรือหมายเลขบั๊กกำกับ
    Radar อย่างบั๊ก #1,000,000 นี่ค่อนข้างพิเศษ
    เว้นแต่จะมีใครเผลอทำให้ทั้งทีมผิดหวัง โดยปกติมันมักเป็น Radar ปลอมที่เต็มไปด้วยมุกวงใน
    แค่เปิดดูรายการเดียวก็พอแล้ว เพราะ Radar อ้างอิง Radar อื่นได้ จึงมักพาเราหลุดเข้า rabbit hole แล้วสนุกไปกับมัน
    ตอนมีโอกาสแล้วไม่ได้แคปเจอร์หรือพิมพ์เก็บไว้สักสองสามอัน นี่เป็นเรื่องโง่มากจริง ๆ

    • ระบบควบคุมเวอร์ชันแบบ monorepo ของ Google ก็มี ID ที่เพิ่มขึ้นทางเดียวแบบนี้ให้กับทุกการเปลี่ยนแปลง
      น่าเสียดายที่เมื่อไม่กี่ปีก่อน ตอนใกล้ถึงเลขกลม ๆ บางเลข มีคนรันสคริปต์เพื่อแย่งเลข ID นั้นจนระบบเข้าสู่ภาวะ denial of service
      ดังนั้นตอนนี้ระบบจะข้าม ID แถว ๆ เลขกลมใหญ่ ๆ ไป :(
      เรื่องนี้คงมีบทเรียนบางอย่างเกี่ยวกับการออกแบบ schema อยู่
    • ในทางกลับกัน ถ้าคิดถึงวิธีที่ Apple จัดการกับ ข้อมูลลับ แล้ว ต่อให้ดูไร้พิษภัยแค่ไหน ก็คงไม่อยากถูกจับได้ว่าลักลอบเอาเอกสารภายในออกมา

  • ไหน ๆ ก็พูดถึง repository ID ของ GitHub แล้ว repository แรกอยู่ที่นี่
    https://api.github.com/repositories/1
    https://github.com/mojombo/grit

  • น่าจะใช้สคริปต์คอยเช็ก https://api.github.com/repositories/999999999 ซ้ำ ๆ แล้วพอมันโผล่ขึ้นมาก็สร้าง repository ใหม่ทันที
    repository แก้ไขได้ ดังนั้นอาจสร้างเผื่อไว้หลายอัน แล้วลบอันที่ไม่ได้หมายเลขที่ต้องการทิ้งทีหลังก็ได้
    ถ้าดู repository อื่นที่ผู้เขียนสร้างเมื่อวาน “yep” น่าจะเป็นเลขวิเศษ ส่วน “shit” น่าจะเป็นการยอมรับว่าพลาดเป้า
    มีใครจำ D666666 ของ Facebook ได้ไหม?
    มันเป็นการแปลงโค้ดขนาดใหญ่ และผู้เขียนก็ใช้เทคนิคคล้าย ๆ กันเพื่อให้ได้หมายเลขเฉพาะนั้น

    • หรืออาจไม่ใช่ก็ได้
      ไม่รู้ว่าทำไมถึงสันนิษฐานว่าคนนี้ตั้งใจจอง repository นั้น
    • เพราะเป็น repository ว่าง ๆ เลยน่าจะใช่

  • ถ้าพูดจริงจัง ผมแปลกใจนิดหน่อยที่ GitHub ทำให้การคำนวณความเร็วในการสร้าง repository ใหม่ง่ายขนาดนี้
    ข้อมูลแบบนี้ปกติไม่ใช่ ความลับของบริษัท เหรอ?

    • ถ้าคูเมืองกว้างถึง 1 พันล้านช่อง ก็คงเผลอเดินไปไหนมาไหนในชุดชั้นในได้บ้างแหละ
    • GitHub มีเหตุผลอะไรที่ต้องซ่อนข้อมูลนี้ไหม?
      ผมนึกไม่ออกว่าจะเอาเรื่องนี้ไปใช้ให้ GitHub เสียเปรียบได้อย่างไร
      เข้าใจอยู่ว่าหลายบริษัทตั้งค่าเริ่มต้นไว้ว่าไม่เปิดเผยข้อมูลใด ๆ เว้นแต่จะถูกบังคับ
    • ถ้าใช้ binary search ก็หา ID ล่าสุดได้เร็วมากเช่นกัน
      เมื่อก่อนเคยติดตามการเติบโตของหลายเว็บไซต์ด้วยวิธีนี้
    • ยังดูความเร็วในการสร้างผู้ใช้ใหม่ได้ด้วย
      ในแง่หนึ่ง ฝั่งนั้นน่าสนใจกว่าด้วยซ้ำ

  • สงสัยว่า AasishPokhrel สร้าง repository นี้เพื่อให้เป็น repository ลำดับที่ 1 พันล้าน หรือเปล่า

    • AasishPokhrel สร้าง repository 2 อันเมื่อวาน ชื่อ “shit” กับ “yep”
      ระหว่างวันที่ 17 พฤษภาคมถึง 10 มิถุนายนไม่มีความเคลื่อนไหว
      ไม่แน่ใจว่าจะคำนวณอัตราการสร้าง repository แล้วสร้างให้ตรงกับหมายเลขที่ต้องการได้ไหม
    • เรื่องนี้ปั่นได้ค่อนข้างง่าย
      ก็สร้าง repository ไปเรื่อย ๆ จนกว่าจะได้ลำดับที่ 1 พันล้าน แล้วลบอันก่อน ๆ ทิ้ง
      ด้วย GitHub API นี่ง่ายมาก
      ปัญหามีแค่ rate limit กับคนอื่นที่กำลังสร้าง repository พร้อมกัน ดังนั้นสุดท้ายก็เป็นเรื่องของดวง
    • ดูเหมือนเขาจะเป็นนักศึกษามหาวิทยาลัยที่เรียน software development ในเนปาล ซึ่งการที่ milestone แบบนี้ไปถึงผู้คนลึก ๆ ทั่วโลกได้ เป็นเรื่องที่ซาบซึ้งจริง ๆ
      หวังว่าเขาจะใส่เรื่องนี้ไว้เด่น ๆ ในเรซูเม่ แล้วหาเส้นทางอาชีพดี ๆ ในสายพัฒนาได้
    • น่าสงสัยมาก แต่ก็ดูเป็นไปได้

  • repository นั้นถูกเปลี่ยนชื่อ และตอนนี้ดูเหมือนจะ redirect ไปที่ https://github.com/AasishPokhrel/repository/
    ไม่ค่อยดีเลย :-(

    • เปลี่ยนกลับเป็นชื่อเดิมแล้ว! :-D

  • สงสัยว่าถ้ารวมเซิร์ฟเวอร์ Forgejo กับ GitLab แบบโลคัลทั้งหมดเข้าไปด้วย จะมี repository รวมทั้งหมดเท่าไรกันนะ
    รวมถึง Subversion, Mercurial, เพื่อน ๆ อื่นของ git และแม้แต่ศัตรูด้วย
    มีใครทำ search engine สำหรับของพวกนี้ไว้แล้วหรือยัง?
    ถ้าค้นคำอย่าง “a” แล้วประมาณขนาดคร่าว ๆ ได้ก็คงดี
    ข้อดีใหญ่ของ GitHub ที่รวมศูนย์ดูเหมือนจะเป็นการที่ผู้คนสามารถหาโค้ดของผมเจอได้จริงเสมอ
    หลัง Microsoft ซื้อ GitHub ผมเคยคิดจะทำ search แต่สุดท้ายก็ไม่ได้ทำ เพราะคิดว่าน่าจะสู้ด้านการตลาดไม่ไหวและกลายเป็นงานเปล่า
    ช่วงหลังผมเอาหลายโปรเจกต์ไปลง Codeberg แล้วก็กลับมาคิดอีกครั้งว่ามันคุ้มจะลองไหม แต่ก็อาจมีใครชิงทำไปก่อนแล้วก็ได้

    • จากวิธีไล่ enumerate ผ่าน API ที่พูดถึงในคอมเมนต์พี่น้อง ดูเหมือนจะไม่จำเป็นต้องประมาณก็ได้
      https://docs.gitlab.com/api/projects/#list-all-projects — ด้วยเหตุผลแปลก ๆ GitLab ดูเหมือนจะเรียกมันว่า project ไม่ใช่ repository
      https://codeberg.org/api/swagger#/repository/repoGetByID — ลิงก์มาจากไซต์ Forgejo.org ดังนั้นก็น่าจะเหมือนกันทั้ง Forgejo และ Codeberg
      แล้วก็เพื่อนคนนั้น https://gitea.com/api/swagger#/repository/repoGetByID
      Heptapod เป็น “friendly fork” ของ GitLab CE ดังนั้น API ก็น่าจะทำงานเหมือนกัน: https://heptapod.net/pages/faq#api-hgrc
      ต่อจากนั้นคงต้อง index อินสแตนซ์ GitLab รายโปรเจกต์ต่าง ๆ: Gnome, GNU (ถ้าสักวันเปิดให้ใช้อีก), สถานการณ์ฝั่ง Savannah, อาจรวมถึง Sourceforge และบางที sourcehut ด้วย
      ถ้าถูกลอตเตอรี่ ผมอยากออกทุนให้รันอินสแตนซ์ sourcegraph สมัยที่ยังเป็น Apache License ครอบคลุมให้มากที่สุด แล้วบริจาค snapshot นั้นให้ Internet Archive
    • Software Heritage ทำรายการ public repository 380 ล้านรายการ แล้ว และในนั้น 280 ล้านรายการอยู่บน GitHub: https://archive.softwareheritage.org/
      การค้นหา repository ยังจำกัดอยู่พอสมควร คือทำได้แค่ค้น full text ของ URL หรือค้นไฟล์ metadata จำนวนน้อยอย่าง package.json เท่านั้น

  • https://ohshitgit.com