1 पॉइंट द्वारा GN⁺ 2023-11-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GitHub Community चर्चा में यह मुद्दा उठाया गया कि सार्वजनिक repositories की code search भी अब लॉगिन के बिना इस्तेमाल नहीं की जा सकती, और सवाल पूछने वाले ने आलोचना की कि इससे सार्वजनिक code की accessibility और open source की उपयोगिता को नुकसान पहुंचता है
  • GitHub maintainer ने जवाब दिया कि सभी repositories पर search के लिए बहुत पहले से लॉगिन जरूरी था, और 2023 की शुरुआत में search feature को मजबूत करते समय individual repository search पर भी लॉगिन की शर्त बढ़ा दी गई
  • GitHub की ओर से कारण यह है कि developers के लिए search load को संभाला जा सके और bots आदि की anonymous requests से servers के overwhelmed होने की स्थिति कम की जा सके
  • चर्चा में शामिल लोगों ने सवाल उठाया कि public repositories को अब भी clone करके local search किया जा सकता है, इसलिए login requirement bots रोकने के लिए पर्याप्त है या नहीं; उन्होंने rate limit, CAPTCHA, और सरल search restrictions जैसे विकल्पों का जिक्र किया
  • व्यावहारिक रूप से, non-logged-in users अब public code search links सीधे नहीं खोल सकते, इसलिए grep.app, github1s, local grep, सामान्य search engines, और कई Git forge mirrors जैसी workarounds पर भी चर्चा हुई

सार्वजनिक code search पर login requirement लागू हुई

  • GitHub Community Discussion #77046, जिसका शीर्षक “Can no longer search code without being logged in” है, उस स्थिति पर चर्चा करता है जिसमें लॉगिन के बिना code search संभव नहीं रह गई है
  • सवाल पूछने वाले ने बताया कि वे एक पुराने device से अपनी repositories में कुछ search करने की कोशिश कर रहे थे, लेकिन login requirement की वजह से आगे नहीं बढ़ पाए
    • उन्होंने कहा कि उन्हें password manager तक access करना था, 2FA और YubiKey की जरूरत थी, और पुराने laptop में USB-C port न होने के कारण वे अटक गए
    • उन्होंने बताया कि वे चाहते थे कि लोग public repository code search का उपयोग कर सकें
  • सवाल पूछने वाले ने आलोचना की कि यदि repository public है तो clone करके dedicated tools से search और analysis किया जा सकता है, इसलिए web code search पर login requirement रखना समझना मुश्किल है
  • इस चर्चा को GitHub की ओर से जवाब के बाद Answered के रूप में चिह्नित किया गया, और page पर 19 comments और 58 replies दिखते हैं

GitHub का जवाब और आधिकारिक आधार

  • GitHub maintainer martinwoodward ने असुविधा के लिए माफी मांगते हुए जवाब दिया कि सभी repositories पर search के लिए बहुत पहले से login जरूरी था
  • उन्होंने समझाया कि 2023 की शुरुआत में search feature को बेहतर बनाते समय individual repository search पर भी login requirement बढ़ाई गई
  • उन्होंने बताया कि मुख्य उद्देश्य GitHub developers के लिए search load को support करना और bots आदि की anonymous requests से servers के overwhelmed होने से रोकना है
  • चर्चा के दौरान एक अन्य participant ने GitHub की नई code search implementation पर आधारित The technology behind GitHub’s new code search link दिया

विरोध का मुख्य मुद्दा: public repositories और open source accessibility

  • कई participants का मानना था कि public repository code को login के बिना clone किया जा सकता है, इसलिए public code search तक login से रोकना जरूरत से ज्यादा सख्त कदम है
  • एक participant ने बताया कि बाहरी users को अपना public source देखने के लिए GitHub login करने को मजबूर करना असुविधाजनक है
    • उदाहरण के तौर पर उन्होंने कहा कि वे repo:USER/REPO, path:..., AND NOT path:**/_externals जैसे search queries को single URL या button के रूप में share करना चाहते थे
    • उन्होंने कहा कि login requirement की वजह से उन्हें इसे कई direct file URL lists से बदलना पड़ता है
  • अन्य participants ने GitHub के “world's largest open source community” कहने और public code search restrictions के बीच तनाव की ओर इशारा किया
  • कुछ comments ने याद किया कि Microsoft acquisition से पहले भी ऐसी ही restrictions थीं, और कहा कि यह restriction पूरी तरह नई नहीं है

bot prevention और cost पर बहस

  • GitHub ने anonymous bot requests से आने वाले load को कारण बताया, लेकिन कुछ participants ने तर्क दिया कि login requirement dedicated bot operators को रोकने में मुश्किल से ही काम करेगी
  • विकल्प के तौर पर पहले rate limit लागू करने और limit तक पहुंचने पर CAPTCHA या login मांगने का तरीका सुझाया गया
  • यह counterargument भी आया कि public repositories anonymous clone की अनुमति देती हैं, इसलिए bots local search पर switch कर सकते हैं
    • इसके जवाब में एक अन्य participant ने कहा कि clone GitHub की search computing का उपयोग नहीं करता, इसलिए यह denial-of-service vector को कम करता है
    • यह भी बताया गया कि cloned data जल्दी stale हो सकता है
  • यदि search cost ज्यादा है, तो simple queries को non-logged-in users के लिए अधिक simple तरीके से उपलब्ध कराने और complex queries को logged-in users के लिए रखने का अलगाव भी सुझाया गया

search feature की अपनी सीमाएं और comparison cases

  • एक participant ने कहा कि logged-in होने पर भी path:contributing.md से सभी public repositories में search करते समय सिर्फ 5 pages results मिलते हैं
    • एक अन्य participant ने कहा कि यह किसी खास query की समस्या नहीं, बल्कि current search की limitation है, और संबंधित discussion के रूप में GitHub Community Discussion #9868 का जिक्र किया
  • एक अन्य participant ने SourceForge, Google Code archive, GitLab, और Bitbucket के search behavior की तुलना की
    • उन्होंने कहा कि SourceForge और Google Code archive में search नहीं है
    • GitLab में global search के लिए login जरूरी है, जबकि per-repository search संभव है
    • Bitbucket search login पर redirect करती है, लेकिन repository मिल जाने पर login के बिना search संभव है

workaround methods और alternative services

  • non-logged-in state में single repository को जल्दी search करने के तरीके के रूप में local clone के बाद grep इस्तेमाल करने की प्रक्रिया बताई गई
    • /dev/shm पर जाएं
    • git clone https://github.com/user/repo
    • repository में जाएं और grep -r "pattern" . चलाएं
    • search के बाद repository delete करें
  • पूरे GitHub पर pattern search के लिए general search engine में "pattern" site:github.com इस्तेमाल करने का तरीका बताया गया
    • हालांकि साथ में यह limitation भी बताई गई कि यह GitHub built-in search जितना powerful नहीं है, और कुछ code index नहीं हो सकता
  • alternative या auxiliary tool के रूप में grep.app का जिक्र हुआ, और बताया गया कि इससे login के बिना repository search की जा सकती है
  • GitHub URL में github.com की जगह github1s.com इस्तेमाल करने पर repository को online VS Code रूप में खोलने की tip भी share की गई
  • alternative Git forges के रूप में GitLab, Framagit, Gitea, Forgejo, Codeberg, Gogs आदि का जिक्र हुआ, और कहा गया कि इनमें से कुछ self-host करने पर code search enable कर सकते हैं

project hosting method पर सलाह

  • एक participant ने सलाह दी कि GitHub को project का एकमात्र code forge नहीं, बल्कि mirrors में से एक मानें
  • उन्होंने समझाया कि Git एक distributed version control system है, इसलिए केवल GitHub का उपयोग करने पर यह single point of failure बन जाता है
  • उदाहरण के तौर पर कई remotes जोड़कर GitHub, Codeberg, Framagit, और private repository में अलग-अलग push करने का तरीका बताया गया

1 टिप्पणियां

 
GN⁺ 2023-11-29
Hacker News की राय
  • इस मामले को सबसे उदार नज़रिए से देखें तो, नया GitHub code search वास्तव में इस्तेमाल करने पर बहुत बेहतरीन है और सामान्य search engine की तुलना में अंदर ही अंदर कहीं ज़्यादा काम करता है, इसलिए यह resource-heavy फीचर हो सकता है
    इसे login account तक सीमित करने से crawler handling में लगने वाले server resources काफ़ी बचाए जा सकते हैं। यहाँ समझौता शायद इस बात के करीब है कि search infrastructure पर 3~4 गुना या उससे अधिक खर्च किया जाए, या फिर login की शर्त लगाकर आलोचना झेली जाए। मैंने खुद GitHub repositories के लिए code search tool बनाया है, लेकिन GitHub का default code search इतना उपयोगी है कि अब उसका लगभग इस्तेमाल ही नहीं करता: https://simonwillison.net/2020/Nov/28/datasette-ripgrep/

    • सबसे व्यावहारिक वजह शायद यह लगती है कि लोग झुंझलाएँगे, लेकिन अंत में account बना ही लेंगे, और GitHub नए उपयोगकर्ताओं की वृद्धि का दावा कर सकेगा
      दूसरी ओर, मौजूदा उपयोगकर्ता इस बात से नाराज़ हो सकते हैं कि login के बिना search भी नहीं कर सकते। किसी और के PC, public PC, incognito tab, या 2-step authentication में लगने वाले समय जैसी स्थितियों में यह काफ़ी असुविधाजनक है। GitHub चाहे तो बिना login वाले उपयोगकर्ताओं के लिए सस्ता और तेज़ basic search छोड़ सकता था, लेकिन उसने ऐसा नहीं किया
    • तकनीकी कारण दिलचस्प हैं, लेकिन यही मूल मुद्दा नहीं है
      नतीजतन, अब GitHub में sign up किए बिना “GitHub पर host किए गए open source” में भाग लेना संभव नहीं रह गया है
    • कई वजहें बताई जा रही हैं, लेकिन असल में संभावना ज़्यादा यही लगती है कि वे AI-संबंधित कंपनियों और शोधकर्ताओं की content scraping से बचना चाहते हैं, या उनसे बचना उनके लिए ज़रूरी हो गया है
    • अगर यह जानबूझकर किया जा रहा है, तो Microsoft वाकई सबसे खराब है, और अगर यह सिर्फ अक्षमता है, तो इतनी आसान चीज़ भी बिगाड़ देना हैरान करने वाला नहीं है
      grep 50 साल पुराना tool है, और text search के लिए खुद code लिखने की भी ज़रूरत नहीं है; free software इस्तेमाल किया जा सकता है। यह कोई एक CRUD app और 3 developers वाला amateur startup भी नहीं, बल्कि दुनिया की सबसे बड़ी और सबसे अमीर tech companies में से एक है, और वह login के बिना ठीक से text search भी नहीं कर पा रही — यह शर्मनाक है। अगर कोई तीसरी व्याख्या है, तो मैं उसे सुनना चाहूँगा
    • अंदरूनी code search तो बस Elasticsearch है, इसमें कुछ खास नहीं
      GitHub की व्याख्या कुल मिलाकर बकवास जैसी लगती है। public endpoint पर ज़बरदस्ती authentication लगाना उस समस्या का सही समाधान नहीं है जिसका वे दावा कर रहे हैं। इस endpoint में दिलचस्पी रखने वाले bot बनाने वाले लोग मुफ्त account से login करवा देंगे, इसलिए इससे server load भी कोई अर्थपूर्ण ढंग से नहीं रुकेगा
  • यह कम-से-कम 6 महीने पहले शुरू हो चुका था और changelog में इसकी घोषणा भी की गई थी: https://github.blog/changelog/2023-06-07-code-search-now-req...
    HN चर्चा: https://news.ycombinator.com/item?id=36230929

    • यह हैरानी की बात है कि इसे जैसे कोई नई खबर हो, वैसे पोस्ट किया गया। यह तो पहले से कई साल पुरानी बात जैसा महसूस होता है, यहाँ तक कि याद भी नहीं कि आख़िरी बार बिना login के search कब किया था
      business नज़रिए से देखें तो यह क्यों किया गया, यह पूरी तरह समझ आता है। इससे लोगों को सचमुच उपयोगकर्ता में बदला जाता है और user engagement बढ़ती है
  • अब GitHub को खुले platform की तरह मानना बंद कर देना चाहिए
    GitHub भी दूसरी सेवाओं की तरह एक बंद घेराबंदी वाला ecosystem है। सिर्फ इसलिए कि यह हमारे इस्तेमाल के बहुत से open source projects को host करता है, यह बेहतर नहीं हो जाता; बल्कि शायद और बुरा हो जाता है। क्योंकि इसने इन projects के contribution infrastructure के एक हिस्से को corporate account के ताले के पीछे धकेलने में मदद की है

    • उपयोगकर्ता के नज़रिए से देखें तो “corporate account” में sign up करना, किसी मनमाने self-hosted GitLab account में sign up करना, या Bugzilla, wiki और किसी git चीज़ में sign up करना — सब एक जैसा ही है
      बल्कि इनमें GitHub account मुझे बेहतर लगता है। क्योंकि बिना बार-बार नया account बनाए या login किए भी लगभग अनगिनत projects में भाग लिया जा सकता है। यह कहना मुश्किल है कि GitHub ने इस क्षेत्र के दूसरे विकल्पों की तुलना में वास्तव में कुछ अलग तरह से रोका है। GitHub ने अच्छा software बनाया और उसे मुफ्त में दिया, उसे काफ़ी खुला और सुलभ बनाए रखा, जहाँ standards थे वहाँ उनका पालन किया, बाकी जगह API दिए, और open source projects को भारी storage और computing मुफ्त में उपलब्ध कराई है
    • यह भी कहना चाहिए कि GitHub ने अनगिनत open source projects की वृद्धि में मदद की है
      इसमें Git hosting, wiki hosting, issues, GitHub Actions, GitHub Pages, और ठीक-ठाक API भी हैं। open source project को GitHub पर रखने की बहुत सी वजहें हैं
  • 2023 में वेब सच में बंद हो गया। StackOverflow, Reddit, GitHub और Twitter—सबने स्क्रैपिंग और API access पर रोक लगानी शुरू कर दी।
    इसकी शुरुआत AI training को रोकने और profitability के दबाव के साथ हुई। tech मंदी, Stack और X के नए मालिक, और Reddit के IPO जैसे commercial realities भी कारण थे। लंबे समय में proprietary data market के बढ़ने की संभावना दिखती है। search engine, AI tools, और data की ज़रूरत रखने वाले किसी भी व्यक्ति को source data streams या API access के लिए पैसे देने होंगे, और अगर केवल सबसे अमीर कंपनियाँ ही वह data खरीद पाएँगी, तो यह antitrust समस्या तक जा सकता है

    • आखिरकार सब लोग यह सामान्य मानने लगेंगे कि “StackOverflow, Reddit, GitHub, Twitter” दूसरों द्वारा बनाए और स्वामित्व वाले content तक पहुँच बेचते हैं।
      अगर कोई चीज़ सच में proprietary data है, तो उसका भुगतान किसी मनमाने Git server operator को नहीं बल्कि मालिक को मिलना चाहिए। कीमत और शर्तें भी server operator नहीं बल्कि मालिक को तय करनी चाहिए। अगर server को पैसा कमाना है, तो वह अपनी base service के लिए शुल्क ले सकता है। दूसरी ओर, अगर किसी ने कुछ बाँटने के इरादे से बनाया था, और उस समय platform ने ऐसे वितरण के लिए प्रभावी channel दिया था और खुद को उसी के लिए उपयुक्त बताकर प्रचार किया था, तो बीच में नियम बदल देना नैतिक रूप से उस व्यक्ति के काम की piracy है। ऐसे platforms पर मौजूद सामग्री का बड़ा हिस्सा शायद कभी अपलोड ही नहीं होता, अगर असली मालिकों को मनमानी पाबंदियों और access fees की उम्मीद होती। अगर नियम इतने कट्टर तरीके से फिर से लिखे जाने हैं, तो पुराना content केवल उन्हीं मामलों में बेचा जाना चाहिए जहाँ मूल रचनाकार ने स्पष्ट सहमति दी हो। लेकिन Reddit तो ऐसे उपयोग का विरोध करने के लिए bulk deletion करने वाले लेखकों की पोस्ट तक सक्रिय रूप से restore करता रहा है
    • यह रुझान पहले से मौजूद था, लेकिन इस साल यह खास तौर पर ज़्यादा बंद हुआ।
      https://theoatmeal.com/comics/reaching_people
    • निष्पक्ष रूप से देखें तो GitHub अब भी code search को छोड़कर अपनी ज़्यादातर functionality public anonymous API endpoints के ज़रिए देता है।
      बस rate limits कहीं ज़्यादा सख्त हैं। GitHub account बनाना मुफ़्त है और बहुत intrusive भी नहीं है। login करने पर भी server को गिराने से रोकने के लिए सभी APIs पर वैसे भी rate limiting है। इसी वजह से https://gitstar-ranking.com/ जैसे tools, जो मुफ़्त account से सभी repositories के GitHub stars scrape करने की कोशिश करते हैं, मुश्किल में पड़ते हैं। असल में महत्वपूर्ण data यानी source code को HTTPS endpoint से anonymous clone किया जा सकता है, और उसके अंदर search किया जा सकता है। https://grep.app/ जैसी third-party sites भी यही तरीका इस्तेमाल करती हैं। Reddit/Twitter के मामले में source data—posts, comments, upvotes, tweets—अब API से उपलब्ध नहीं है, इसलिए third-party tools बनाना मुश्किल या असंभव हो गया है। लेकिन GitHub में source data तक पहुँचना अभी भी आसान है, और बिना login वाले users के लिए सिर्फ search जैसी auxiliary layer को रोका गया है, इसलिए स्थिति काफ़ी अलग है
    • यह सही भी है और नहीं भी। ExpertsExchange जवाबों को “दीवार के पीछे” रखने के लिए बदनाम था, और StackOverflow से काफ़ी मिलता-जुलता था।
      याद है कि जब StackOverflow लॉन्च हुआ था, तो उसकी तुलना expertsexchange से की जाती थी और उसे “open” माना जाता था। अब समय आ गया है कि centralized services से हटकर ज़्यादा distributed और microtransaction-based संरचना की ओर जाया जाए। HN के बहुत से लोगों को यह पसंद नहीं आएगा, लेकिन Q&A forums, news links और comments aggregation, Git hosting और approval workflows, wikis और ticket systems—ये सब पूरी तरह distributed तरीके से बनाए जा सकते हैं और बनाए जाने चाहिए। Kademlia/BitTorrent technology, IPFS, और microtransaction payments के लिए CryptoTokens जैसे तरीके संभव हैं। 100% distributed होना ही इन चीज़ों को लगातार “open” बनाए रखने और corporate greed से मुक्त रखने का रास्ता है। संस्थापक चाहे अच्छे इरादों से शुरू करें, लंबे समय में product बिक जाता है और accountants नियंत्रण संभाल लेते हैं—यह बार-बार हुआ है
  • सद्भावनापूर्ण व्याख्या करें तो search में काफ़ी computing लगती है, इसलिए यह एक बड़ा denial-of-service attack vector भी बन सकता है।
    GitHub login users से कितना behavioral data इकट्ठा कर सकता है, और वह पहले से public code की तुलना में कितना उपयोगी है, यह स्पष्ट नहीं है। शायद इसका उपयोग यह समझने में किया जा सकता है कि code के कौन से हिस्से महत्वपूर्ण हैं, लेकिन उसे user-specific जानकारी कहना मुश्किल है

    • search देने वाले हर व्यक्ति के लिए यह सचमुच की समस्या है।
      मेरे search engine traffic का लगभग 0.5% ही इंसान होता है। जिन search engines के पास ऐसे आँकड़े नहीं हैं, उनके बारे में पता नहीं
    • यह behavioral data collection बिल्कुल Microsoft-स्टाइल है, इसलिए इसे लेकर सद्भावना मानने की ज़रूरत नहीं है।
      MS acquisition day के बाद से मेरे हिसाब से किसी भी open source project के उस platform पर बने रहने का कोई उचित कारण नहीं है। और git clone करके जाने के लिए अच्छे alternatives की कमी भी नहीं है
    • एक और कारण यह है कि अगर किसी विशाल code corpus पर anonymous faceted regex search की अनुमति हो, तो malicious users hardcoded credentials ढूँढ़कर अतिरिक्त systems तक पहुँच बना सकते हैं, और ठीक से audit trail छोड़ना भी मुश्किल होगा।
      इसलिए API को lock down करने के कई संभावित कारण हैं
  • जब login नहीं होता, तो मैं Sourcegraph इस्तेमाल करता हूँ। पुराने search की तुलना में यह काफ़ी बेहतर भी है।
    यह इतना आसान है कि repository URL को github.com से शुरू होने वाले रूप में paste कर दें। उदाहरण के लिए sourcegraph.com/github.com/rust-lang/rust/ पर इस repository में unit खोजा जा सकता है

  • Microsoft की AI moat का एक हिस्सा यह नियंत्रित करना भी है कि competitors GitHub की जानकारी का इस्तेमाल कितनी आसानी से कर सकें।
    अगर अगला कदम git clone को सीमित करना हुआ, तो मुझे हैरानी नहीं होगी

    • अगर git clone को सीमित किया गया, तो इतने सारे CI systems टूट जाएँगे कि हैरानी होगी।
      NPM का बड़ा हिस्सा, Go package management, Jenkins scripts आदि को अलविदा कहना पड़ेगा
    • अगर code login के पीछे या यहाँ तक कि paid subscription के पीछे हो, तो क्या repository license के अनुरूप उसे अब भी open source कहा जा सकता है, यह सोचने वाली बात है।
      जहाँ तक याद है, GitHub पहले से excessive clone या API usage को धीमा करने के लिए rate limiting करता है
  • भले ही मैं सवाल उठाने वाले की स्थिति से सहमत हूँ, फिर भी मुझे नहीं लगता कि इसे इस तरह कहने की ज़रूरत थी।
    मैं उस रुख से पूरी तरह सहमत भी नहीं हूँ, क्योंकि search हमेशा सस्ता नहीं होता और DOS-शैली के हमलों में इस्तेमाल हो सकता है। “क्या अब यह इतना भी काफ़ी नहीं कि हर चीज़ से कमाई करो, अब यह भी ट्रैक करना चाहते हो कि मैं कौन-सी code line देख रहा हूँ?” जैसी बातों से क्या मदद मिलती है, समझ नहीं आता। थोड़ा शांत होने की ज़रूरत है। मूल तर्क भी इतना मज़बूत नहीं है। repository खुद login के पीछे बंद नहीं है, इसलिए public repository clone सहित सार्वजनिक रूप से accessible है। अगर लेखक चाहता है कि उसकी repository और code जनता के काम आए, तो केवल download और search से आगे बढ़कर issue बनाते समय या PR भेजते समय contributor को वैसे भी login करना ही पड़ेगा

    • source code में तेज़ी से search करने की ज़रूरत बहुत बार पड़ती है
      यह समझने के लिए कि कोई चीज़ कैसे काम करती है, या जब GitHub issue के अलावा कहीं और चर्चा हो रही हो। clone आम तौर पर तेज़ होता है, लेकिन बहुत बड़ी repository में ऐसा नहीं होता, और हो सकता है कि मौजूदा device में clone करने की जगह ही न हो। ऊपर से अगर login करने के बजाय बहुत-से लोग हर बार clone करने लगें, खासकर जब GitHub login 2-factor authentication की वजह से झंझट भरा हो, तो इससे system load सच में घटेगा भी या नहीं, इस पर संदेह है। हर कोई GitHub account रखना भी नहीं चाहता
  • HackerNews: अब पहला पेज बिना यह शिकायत देखे नहीं खुलता कि login न किए हुए users को free और ad-free service नहीं मिल रही

    • “अगर कुछ free है, तो product आप ही हैं” वाली कहावत ज़्यादातर मामलों में सही है
      इस मामले में आपका code Copilot training वगैरह में इस्तेमाल हो रहा है। और मान लें कि ऐसा नहीं भी हो, और service सच में उतनी ही सदाशयी हो जितनी आप मानते हैं, तब भी क्या आप काफी users के लिए service खराब होती देखकर ताली बजा सकते हैं? क्या यह कोई दिलचस्प और रोमांचक बात है?
    • क्या उस दावे के लिए कोई आधार है? मैं लगभग हर दिन HN देखता हूँ, लेकिन “login के बिना X नहीं कर सकते” तरह की पोस्ट मुझे खास लोकप्रिय लगती नहीं हैं
      जो एकमात्र उदाहरण याद आता है वह Reddit का API बदलाव है, लेकिन वह काफी पुरानी बात है और login से उसका संबंध भी बस ढीला-ढाला है
  • अगर आप open source search जारी रखना चाहते हैं, तो https://sourcegraph.com/search में login की ज़रूरत नहीं है, और इसमें GitHub पर न मौजूद कई बड़े project भी शामिल हैं
    जानकारी के लिए, मैं Sourcegraph CTO हूँ

    • मैं अपने personal GitHub account से office computer पर login नहीं करना चाहता, इसलिए जब भी repository search की ज़रूरत होती है, मैं हमेशा Sourcegraph इस्तेमाल करता हूँ
      पहले मैं चाहता था कि GitHub search git clone + grep का मुकाबला कर सके, लेकिन यह नहीं सोचा था कि इसकी कीमत login barrier के रूप में चुकानी पड़ेगी। जहाँ तक याद है, मैंने सोचा था कि login barrier सिर्फ beta feature होने की वजह से है, और जब यह default search बनेगा तो इसे हटा दिया जाएगा
    • यह जानने की जिज्ञासा है कि search को बिना login के क्यों अनुमति दी गई, लेकिन Cody के लिए login क्यों ज़रूरी रखा गया