GitHub पर 1 अरबवां repository बनने का जश्न

 (github.com/AasishPokhrel)
2 पॉइंट द्वारा GN⁺ 2025-06-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GitHub उपयोगकर्ता jonmagic ने Issue #1 में GitHub के 1 अरबवें repository के बनने का जश्न मनाया और बताया कि repository shit के पास यह ID है
  • सबूत के तौर पर दिए गए curl -s रिस्पॉन्स में id 1000000000, node_id R_kgDOOO5rKAA, name shit, full_name AasishPokhrel/shit शामिल थे
  • कमेंट थ्रेड repository के नाम और 💩 इमोजी का इस्तेमाल करते हुए बधाई और मज़ाक के इर्द-गिर्द चलता रहा, और शुरुआती पोस्ट पर हज़ारों 👍·😄·🎉 रिएक्शन आए
  • jonmagic ने GitHub डॉक्स के लिंक छोड़ते हुए कहा कि ज़रूरत पड़ने पर repository owner conversation lock या unsubscribe का इस्तेमाल कर सकता है
  • 28 जून 2025 को repository owner ने बातचीत को collaborator तक सीमित करके लॉक कर दिया, और उसी दिन एक कमेंट हटा दिया गया

1 अरबवें repository के रूप में चिह्नित shit

  • Issue का शीर्षक Congratulations on creating the one billionth repository on GitHub! है, और इसमें GitHub पर 1 अरबवें repository के बनने की बधाई दी गई है
  • jonmagic ने repository creator को बधाई देते हुए नीचे दिए API कॉल के आंशिक परिणाम को आधार के रूप में पेश किया
  • बधाई संदेश में repository के नाम पर आधारित मज़ाक भी था, जैसे “उम्मीद है कि आपको शानदार 💩 बनाने का मौका मिले”

कमेंट रिएक्शन और मज़ाक की धारा

  • शुरुआती कमेंट्स ज़्यादातर बधाई और wordplay से भरे थे
    • “कौन-सी शानदार 💩 बनेगी, यह देखने का इंतज़ार है”
    • “इस 💩 के live होने का इंतज़ार नहीं कर सकता”
    • “मैं इसे fork करूँगा”
    • “यह issue lock होने से पहले कमेंट छोड़ रहा हूँ”
  • MangoCubes ने कहा कि jonmagic के GitHub कर्मचारी होने से उसे तसल्ली हुई
  • jordigh ने “क्या कोई ETA या workaround है?” जैसी आम issue-comment शैली की पैरोडी की
  • इसके बाद भी 💩, sssssssshit, “peak shit” जैसे छोटे कमेंट्स आते रहे

notifications की बाढ़ पर मार्गदर्शन

  • jonmagic ने AasishPokhrel को बताया कि ज़रूरत होने पर वह conversation lock कर सकता है या unsubscribe कर सकता है
  • साथ में छोड़े गए डॉक्स लिंक ये दो थे

भागीदारी का पैमाना और रिएक्शन

  • मूल issue बॉडी में हज़ारों रिएक्शन दिखाए गए थे
    • 👍 4524
    • 😄 2116
    • 🎉 2638
    • ❤️ 945
    • 🚀 1201
    • 👀 611
  • कमेंट सूची के बीच में 1136 और आइटम बाकी हैं दिखाया गया, यानी केवल कुछ कमेंट्स ही दिखाई दे रहे थे
  • metadata में कुछ प्रतिभागी और +1092 दिखाया गया

लॉक और उसके बाद की स्थिति

  • 28 जून 2025 को repository owner ने बातचीत को lock किया और उसे collaborator तक सीमित कर दिया
  • उसी दिन luckydonald का एक कमेंट हटा दिया गया
  • issue के नीचे यह सूचना भी दिखती है कि GitHub conversation में हिस्सा लेने के लिए sign up या log in करना होगा

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-06-12
Hacker News की राय

  • OpenStreetMap का 10 करोड़वां changeset याद आ गया
    कुछ लोगों ने, जिनमें मैं भी था, हल्के-फुल्के अंदाज़ में उसे पाने की कोशिश की थी, लेकिन आखिर में वह किसी निशाना साध रहे व्यक्ति को नहीं, बल्कि अफ्रीका का मैप मेहनत से बना रहे एक व्यक्ति को मिला
    पीछे मुड़कर देखें तो यह कहीं ज़्यादा अच्छा और दिल को छूने वाला अंत था, और उस व्यक्ति को पहले OSM award के उम्मीदवार के तौर पर भी नामित किया गया था
    OpenStreetMap में सब कुछ असली operational data है, इसलिए यूं ही बेकार data बनाना मुश्किल है, और इसी वजह से लगता है कि Nवें commit के किसी की तत्काल की गई mapping activity होने की संभावना ज़्यादा है
    GitHub के लिए भी यह एक मज़ेदार achievement है :)
    OSM milestone के बारे में और पढ़ना चाहें तो official blog post: https://blog.openstreetmap.org/2021/02/25/100-million-edits-...
    उस समय changeset activity पर मेरी summary: https://www.openstreetmap.org/user/LucGommans/diary/395954

    • एक बार मेरे दोस्त ने हमारा 10 लाखवां helpdesk ticket बनाने के लिए अपना पूरा workday लगा दिया था
      आखिर उसने यह कैसे किया, मुझे नहीं पता, लेकिन उस achievement को celebrate करने के लिए टीम ने छोटी-सी party भी की थी
      शायद करीब 15 साल पहले की बात है, और उस समय tech industry का काम ज़्यादा मज़ेदार लगता था

  • शानदार! GitHub की अपनी OpenAPI Spec में repository count को int32 overflow होने तक अब बस 1 अरब से थोड़ा ज़्यादा ही बाकी है
    workflow run IDs में यह पहले से हो रहा है
    https://github.com/github/rest-api-description/issues/4511

    • जिस कंपनी में मैंने थोड़े समय के लिए CTO के तौर पर काम किया, वहां जाकर देखा कि एक core table में पहले से ही 1.3 अरब rows थीं, लेकिन primary key के लिए 32-bit integer इस्तेमाल हो रहा था
      उस समय की growth rate के हिसाब से कुछ ही महीनों में primary key value overflow होने वाली थी, इसलिए बड़ी गड़बड़ी टालने के लिए IDs को 64-bit पर ले जाने का project काफी urgent तरीके से चलाना पड़ा
    • कुछ हफ्ते पहले LuaRocks ने 65,535 packages पार किए, जिससे Lua community में थोड़ी समस्या हुई
      यह संख्या LuaJIT में LuaRocks implementation से टकरा गई [1] [2], और कुछ users के CI/CD pipelines और personal workflows fail होने लगे, जिससे परेशानी हुई
      यह काफी जल्दी ठीक हो गया, लेकिन दिलचस्प मामला था
      [1] https://github.com/luarocks/luarocks/issues/1797
      [2] https://github.com/openresty/docker-openresty/issues/276

  • काश मैं अब भी Apple में होता
    यहां ज़्यादातर लोग शायद जानते होंगे कि Apple लंबे समय से Radar नाम का internal tool इस्तेमाल करता है
    हर Radar के साथ एक ID, यानी bug number, जुड़ा होता है
    bug #1,000,000 जैसा Radar काफी खास होता था
    जब तक कोई गलती से पूरी team को निराश न कर दे, आम तौर पर वह internal jokes से भरा हुआ fake Radar होता था
    एक ही खोलना काफी था, क्योंकि Radar दूसरे Radar को reference कर सकता था, और आम तौर पर वहीं से rabbit hole में उतरकर मज़ा आने लगता था
    मौका था तब कुछ को capture या print करके न रखना सच में बहुत बेवकूफी थी

    • Google के monorepo version control system में भी हर change को ऐसा ही monotonically increasing ID मिलता है
      दुर्भाग्य से कुछ साल पहले जब कोई round number करीब आया, तो उस ID को पकड़ने की कोशिश में लोगों ने scripts चला दिए और system denial-of-service जैसी स्थिति में पहुंच गया
      इसलिए अब बड़े round numbers के आसपास की IDs skip कर दी जाती हैं :(
      इसमें शायद schema design को लेकर कोई सबक है
    • दूसरी तरफ, Apple confidential data को जिस तरह handle करता है, उसे देखते हुए, कोई internal document बाहर निकालते पकड़ा जाना मैं नहीं चाहूंगा, भले ही वह कितना भी harmless दिखे

  • GitHub repository IDs की बात चल ही रही है, तो पहला repository यहां है
    https://api.github.com/repositories/1
    https://github.com/mojombo/grit

  • शायद script से https://api.github.com/repositories/999999999 को बार-बार check करते रहे और जैसे ही वह दिखाई दिया, नया repository बना दिया
    repository edit किया जा सकता है, इसलिए हो सकता है कि थोड़ा margin रखकर कई repositories बनाए हों और जो सही number वाले नहीं थे उन्हें delete कर दिया हो
    लेखक ने कल जो दूसरे repositories बनाए, उन्हें देखें तो “yep” magic number था, और “shit” शायद यह स्वीकार करना था कि निशाना चूक गया
    Facebook का D666666 किसी को याद है?
    वह एक बड़ा code transformation था, और लेखक ने खास number पाने के लिए कुछ ऐसा ही तरीका इस्तेमाल किया था

    • या फिर शायद ऐसा नहीं भी हो सकता
      समझ नहीं आता कि लोग क्यों मान रहे हैं कि इस व्यक्ति ने जानबूझकर वह repository हासिल किया
    • खाली repository है, इसलिए लगता है कि सही है

  • गंभीरता से कहें तो, थोड़ा हैरान करने वाला है कि GitHub ने नए repository बनने की रफ्तार का हिसाब लगाना इतना आसान छोड़ रखा है
    ऐसी जानकारी आम तौर पर कंपनी का राज़ नहीं होती?

    • अगर moat 1 अरब चौड़ा हो, तो शायद आप अंडरवियर में थोड़ा घूमने लगते हैं
    • क्या कोई वजह है कि GitHub को यह जानकारी छिपानी चाहिए?
      समझ नहीं आता कि इसे GitHub के खिलाफ कैसे इस्तेमाल किया जा सकता है
      यह समझ में आता है कि कई कंपनियां जब तक मजबूर न हों, कोई भी जानकारी सार्वजनिक न करने को default मानती हैं
    • binary search इस्तेमाल करके latest ID भी बहुत जल्दी ढूंढी जा सकती है
      पहले कई websites की growth को इसी तरह track किया था
    • नए users बनने की रफ्तार भी देखी जा सकती है
      एक तरह से वह ज्यादा दिलचस्प है

  • सोच रहा हूं कि क्या AasishPokhrel ने यह repository इसलिए बनाई थी कि वह 1 अरबवीं repository बने

    • AasishPokhrel ने कल 2 repositories बनाई थीं, “shit” और “yep”
      17 मई से 10 जून के बीच कोई activity नहीं थी
      पता नहीं repository creation rate का हिसाब लगाकर मनचाहे number पर repository बनाना संभव है या नहीं
    • इसे manipulate करना काफी आसान है
      1 अरबवीं आने तक repositories बनाते रहें, और पिछली वाली delete कर दें
      GitHub API से यह बहुत आसान है
      समस्या सिर्फ rate limit और उसी समय repositories बना रहे दूसरे लोग हैं, इसलिए आखिर में किस्मत की बात है
    • लगता है वह नेपाल में software development पढ़ने वाला college student है, और यह वाकई छू लेने वाली बात है कि ऐसा milestone दुनिया के अंदरूनी हिस्सों तक पहुंच सकता है
      उम्मीद है वह इसे अपने resume में प्रमुखता से डाले और development field में अच्छा career पाए
    • बहुत suspicious है, लेकिन संभव तो लगता है

  • लगता है उस repository का नाम बदल गया था और अब https://github.com/AasishPokhrel/repository/ पर redirect हो रही है
    अच्छा नहीं है :-(

    • फिर से original नाम पर वापस आ गई! :-D

  • सोच रहा हूं कि local Forgejo और GitLab servers तक सब मिलाकर कुल repositories कितनी होंगी
    Subversion, Mercurial, git के बाकी दोस्त, और दुश्मन भी शामिल करके
    क्या किसी ने ऐसी चीजों के लिए search engine पहले ही बना दिया होगा?
    “a” जैसे शब्द को search करके लगभग scale का अंदाजा लगा पाना अच्छा होगा
    centralized GitHub का बड़ा फायदा हमेशा यह लगा कि लोग सच में मेरा code ढूंढ सकते हैं
    Microsoft ने GitHub acquire करने के बाद मैंने search बनाने के बारे में सोचा था, लेकिन लगा marketing side संभाल नहीं पाऊंगा और मेहनत बेकार जाएगी, इसलिए नहीं किया
    हाल में Codeberg पर कई projects डालते हुए फिर सोचा कि क्या इसे दोबारा आजमाना worthwhile होगा, लेकिन शायद कोई पहले ही बाजी मार चुका होगा

    • sibling comments में बताए गए API enumeration वाले तरीके को देखते हुए, शायद अंदाजा लगाने की जरूरत नहीं है
      https://docs.gitlab.com/api/projects/#list-all-projects — किसी अजीब वजह से GitLab इन्हें repositories नहीं, projects कहता दिखता है
      https://codeberg.org/api/swagger#/repository/repoGetByID — Forgejo.org site से linked है, तो शायद Forgejo और Codeberg दोनों में समान होगा
      और उसका दोस्त https://gitea.com/api/swagger#/repository/repoGetByID
      Heptapod, GitLab CE का “friendly fork” है, इसलिए API भी उसी तरह काम करता है: https://heptapod.net/pages/faq#api-hgrc
      इसके बाद शायद project-specific GitLab instances को index करना होगा: Gnome, GNU(अगर कभी फिर खोलें), Savannah की स्थिति, शायद Sourceforge, और शायद sourcehut भी
      अगर lottery लग जाए, तो sourcegraph के Apache license वाले दौर की instance को जितनी ज्यादा जगहों पर हो सके चलाने के लिए funding देना चाहूंगा, और उस snapshot को Internet Archive को donate करना चाहूंगा
    • Software Heritage ने 38 करोड़ public repositories को catalog किया है, जिनमें से 28 करोड़ GitHub पर हैं: https://archive.softwareheritage.org/
      repository search अभी भी काफी सीमित है; URL full-text search या package.json जैसी कुछ metadata files की search तक ही है

  • https://ohshitgit.com