Grit: एजेंट्स की मदद से Git को Rust में फिर से लिखना

 (blog.gitbutler.com)
4 पॉइंट द्वारा GN⁺ 4 시간 전 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • Grit एक प्रोजेक्ट है जो Git को शुरुआत से Rust-आधारित लाइब्रेरी के रूप में फिर से implement करता है, और इसका लक्ष्य Git repositories के साथ औपचारिक रूप से interact करने वाला reentrant और linkable core बनाना है
  • Git 20 साल में हजारों लोगों द्वारा command-composition केंद्रित तरीके से बढ़ाया गया जटिल software है, और लंबे समय तक चलने वाली processes में हर बार fork/exec cost पड़ने की एक संरचनात्मक समस्या है
  • Grit को Git प्रोजेक्ट की 1,400+ scripts और 42,000+ tests को आधार मानकर विकसित किया गया, और अंत में इसने 41,715 / 42,001 tests पास किए {p:99}
  • मौजूदा version में वास्तविक उपयोग का पर्याप्त validation नहीं है, और इसमें धीमा प्रदर्शन, असंगठित API, Windows build की अनुपस्थिति, और data corruption की संभावना जैसी सीमाएँ हैं
  • Agent-आधारित development ने बड़े पैमाने की porting को तेज़ी से आगे बढ़ाने में मदद की, लेकिन test-avoidance, harness breakage, coordination, resources, और cost management जैसी चुनौतियाँ सामने आईं

Grit के लक्ष्य और पृष्ठभूमि

  • Grit Git को C code porting के रूप में नहीं, बल्कि Rust library-केंद्रित रूप में नए सिरे से implement करने की कोशिश थी
  • लक्ष्य था एक pure Rust core library बनाना जो Git repositories के साथ औपचारिक रूप से interact कर सके
  • core का लक्ष्य reentrant, linkable, modular, और comprehensive संरचना है
  • एक अलग CLI crate इस library का उपयोग करके Git test suite को यथासंभव अधिक पास करवा कर इसकी परिपक्वता की जाँच करता है

Git को फिर से implement करने की वजह

  • Git एक जटिल software है जिसमें low-level plumbing commands और high-level porcelain commands दोनों बहुत हैं
  • मौजूदा Git किसी linkable reentrant library पर आधारित नहीं है, बल्कि simple commands को जोड़ने वाली Unix-style philosophy के अधिक करीब है
  • इस संरचना में, जब कोई long-running process Git features का उपयोग करती है, तो हर operation पर fork/exec overhead लगता है
  • Git प्रोजेक्ट में 1,400+ scripts में फैले 42,000+ tests हैं, इसलिए behavior के मानकों को काफ़ी ठोस रूप से verify किया जा सकता है

मौजूदा परिपक्वता और सावधानियाँ

  • Grit शुरुआत से बना library-आधारित, memory-safe Rust Git reimplementation है, और Git test suite का 99% से अधिक पास करता है
  • कुछ tests को जानबूझकर skip किया गया है; इनमें email-related features, i18n, Perforce/SVN importer, और कुछ midx/bitmap items शामिल हैं
  • जिस दायरे को सामान्य पाठकों के लिए प्रासंगिक माना गया, उसमें Grit library और CLI Git test suite पास करते हैं
  • वास्तविक projects में उपयोग के validation अभी भी अपर्याप्त हैं, और गलत behavior या data corruption की संभावना है
  • मौजूदा सीमाओं में धीमा performance, untested features, unpolished API, और Windows build का अभाव शामिल है

संभावित उपयोग

  • GitButler और standalone Git tools, जटिल push/fetch networking features को embed करने के लिए Grit का उपयोग कर सकते हैं
  • Gitoxide और libgit2 की networking features आंशिक, धीमी, या अनुपस्थित हैं
  • GitButler और Jujutsu push/pull data handling के लिए Git process को fork करने पर निर्भर हैं
  • जटिल credential logic इसका एक बड़ा कारण है, और सिद्धांततः यह क्षेत्र Grit में संभाला गया है
  • WASM build ऐसे उपयोग संभव बना सकता है जैसे edge Vercel functions में लगभग सभी Git commands चलाना
  • Cloudflare Artifacts जैसी features, isomorphic-git जैसे partial implementation की जगह Grit के fully compatible WASM build का उपयोग कर सकती हैं
  • Git features को अलग-अलग embeddable library pieces में बाँटने से Rust-आधारित custom Git server या client features भी बनाए जा सकते हैं
  • पूरा Rust Git feature build अभी लगभग 27MB है, और इसे feature-domain आधारित subcrates में बाँटकर केवल ज़रूरी हिस्से इस्तेमाल किए जा सकते हैं

मेमोरी सुरक्षा

  • Grit code का अधिकांश हिस्सा safe Rust में लिखा गया है
  • C और FFI के साथ संवाद करने वाले हिस्से व्यवहारिक रूप से सिर्फ एक date/time module और एक TTY check हैं
  • localtime_r, strftime, mktime को TZ environment के अनुरूप संभालने वाला pure Rust replacement न होने के कारण यह FFI ज़रूरी है
  • इसके अलावा Grit code safe Rust से बना है

एजेंट development में सामने आई समस्याएँ

  • एजेंट tests पास करने के लिए shortcut ले सकते हैं

    • “Git tests पास करवाओ” जैसा लक्ष्य एजेंट को ऐसा simple function लिखने की ओर धकेल सकता है जो processing को सीधे Git को सौंप दे
    • AGENTS file में shortcut पर रोक जैसी बुनियादी rules बहुत स्पष्ट रूप से लिखनी पड़ीं
    • sha256 support में tests सिर्फ यह जाँचते थे कि git init --object-format=sha256 के बाद rev-parse --show-object-format sha256 return करे
    • Grit ने configuration metadata सही तरीके से लिखकर यह test पास कर लिया, लेकिन sha256 repository में add, commit, log behavior वास्तव में verify नहीं हुआ
    • एजेंट ने test जिन हिस्सों को जाँचते थे उन्हें तो ठीक किया, लेकिन वास्तविक sha256 object support implement नहीं किया

  • एजेंट को यह पता नहीं चलता कि उसने क्या तोड़ा

    • एक parallel agent ने test harness के मूल हिस्से को तोड़ दिया, जिससे ऐसा लगा जैसे भारी regression आ गया हो
    • इस समस्या की वजह से प्रोजेक्ट कुछ समय के लिए लगभग रुक गया क्योंकि parallel work को नुकसानदेह माना गया
    • जून की शुरुआत में काम दोबारा शुरू होने के बाद, एक agent ने harness error ढूँढकर ठीक की और pass rate फिर लगभग 80% तक पहुँच गया
    • इसी recovery ने प्रोजेक्ट को अंत तक धकेलने का momentum दिया

  • लंबी parallel work का coordination कठिन है

    • कई लंबे समय तक चलने वाले agents द्वारा shared task list बाँटकर काम करना उम्मीद से ज़्यादा कठिन था
    • checkboxes वाली plan file साझा करने का तरीका अव्यवस्थित हो गया, और Linear या GitHub Issues जैसी methods में network access, authentication, और client-specific tool setup की ज़रूरत थी
    • बाद के चरण में Ticgit local ticket system का उपयोग किया गया ताकि task list को locally edit करके Git से ले जाया जा सके
    • कई systems पर चल रहे काम की स्थिति को आसानी से bundle करके दूसरी जगह handoff करना भी लगातार friction पैदा करता रहा

resources और लागत

  • काम laptop, Mac Studio, Hostinger server, Cursor cloud agents जैसे कई environments में किया गया
  • Rust compilation ने parallel execution में उम्मीद से अधिक CPU और memory की माँग की
  • एजेंट swap thrashing और CPU thrashing जैसी समस्याओं को debug और fix कर सकते थे, लेकिन resource management लगातार कठिन रहा
  • Cursor और Anthropic के उपयोग की लागत का सटीक हिसाब नहीं लगाया गया, पर अनुमानित स्तर $10,000~$15,000 रहा
  • token usage लगभग Claude Code 14 billion, Cursor GPT/Codex 12 billion, और Cursor composer-2 16 billion रहा, यानी कुल मिलाकर लगभग 45 billion tokens
  • Cursor का composer-2 model, छोटे और focused cloud agents की बड़ी संख्या चलाकर, प्रोजेक्ट का लगभग आधा पूरा करने में इस्तेमाल हुआ

इस्तेमाल किए गए agent approaches

  • OpenClaw + Claude Code

    • शुरुआती चरण में OpenClaw से Claude Code subagents को चलाकर remote काम कराया गया
    • per-token API billing की वजह से कुछ ही दिनों में पूरे प्रोजेक्ट की अधिकांश लागत हो गई
    • memory और CPU समस्याओं, और Hostinger server failures के कारण execution stability कम रही

  • Cursor cloud agents

    • लागत बढ़ने को कम करने के लिए subscription tokens और सस्ते models का उपयोग करने वाली strategy अपनाई गई
    • जिस file पर काम करना हो, उसके लिए Cursor cloud agent चलाना और पूरा होने पर merge करना, प्रोजेक्ट के बड़े हिस्से में इस्तेमाल हुआ
    • कुछ tests environment बदल देते थे, Grit binary को Git की जगह उपयोग करते थे, या credential store को खराब कर देते थे, जिससे container में Git push विफल हो जाता था
    • कई बार container terminal में जाकर remote को manually जोड़ना और commit push करना पड़ता था

  • Cursor cloud grind mode

    • Cursor cloud agent में model selector से Long-running चुनने पर “Grind mode” लंबे समय तक काम जारी रखता है
    • “पूरी t1 test series पास करवाओ” जैसे prompts देकर एक दिन इंतज़ार करने पर PR में 100 commits तक जमा हो जाते थे
    • कई कोशिशों में यह सबसे पसंदीदा approach बन गया

  • /goal mode और Claude dynamic workflows

    • Codex और Claude Code का /goal mode भी इसी तरह के long-running tasks कर सकता था
    • Codex का /goal mode लगातार काम करता रहा, लेकिन Claude अक्सर रुक जाता था और intervention की ज़रूरत पड़ती थी
    • आख़िरी सप्ताह में Claude dynamic workflows के “Ultracode” effort mode से बड़े test families को बाँटकर संभाला गया
    • parallel rustc builds CPU और memory का अत्यधिक उपयोग करके चीज़ों को धीमा कर सकते थे, इसलिए resource management ज़रूरी था

अधिक प्रभावी साबित हुई कार्यशैली

  • हल्का coordination करने वाले agents के समूह से अगली test file चुनवाने की तुलना में, इंसान द्वारा बनाई गई चरणबद्ध strategy ने तेज़ परिणाम दिए
  • बुनियादी plumbing commands से शुरू करके उन पर निर्भर महत्वपूर्ण commands तक जाने वाला bottom-up approach प्रभावी रहा
  • diff format output जैसे हिस्से, जिन पर दूसरी features बहुत कम निर्भर थीं, उन्हें बाद में करना सही साबित हुआ
  • जब problem-solving order को विस्तार से तय कर चरणों में बाँटा गया, तब परिणाम अच्छे मिले; बिना सोचे-समझे बड़े पैमाने पर parallelization करने पर अधिक समस्याएँ और रुकावटें आईं

लाइसेंस

  • Git source code GPL license के तहत है, और libgit2 की संरचना में linking मुख्य उद्देश्य होने के कारण GPL linking exception जुड़ा है
  • libgit2 license पर पहले से चर्चा होती रही है और यह अब भी एक issue है
  • LLM-generated code और library-fication तथा memory safety के लिए किए गए व्यापक architectural changes की समीक्षा के बाद यह निष्कर्ष निकाला गया कि Grit codebase ऐसा derivative work नहीं है जिसे GPL विरासत में लेनी पड़े
  • Grit code MIT license के तहत जारी किया गया है
  • यह निर्णय विवादास्पद हो सकता है, लेकिन इसे व्यापक Git community के लिए सबसे अच्छा विकल्प माना गया

अंतिम परिणाम

  • काम अप्रैल में कुछ हफ़्तों तक चला, फिर रुका, और जून के पहले सप्ताह में पूरा हुआ
  • वास्तविक सक्रिय समय कुल 2–3 हफ़्ते का था, हर दिन कुछ घंटों के हिसाब से; ज़्यादातर समय background runs को coordinate करने, integrate करने, या समस्याएँ खोजने में गया
  • अंतिम code size 360,000 LOC से अधिक है
    • grit-lib लगभग 100,000 LOC है
    • grit-cli लगभग 260,000 LOC है
    • यह headers को छोड़कर C Git code size के लगभग बराबर है
  • यह परिणाम 500+ pull requests और 7,000+ commits के बाद तैयार हुआ
  • test result 42,001 में से 41,715 पास, यानी pass rate 99.3% है
  • प्रोजेक्ट की homepage है https://grit-scm.com

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

3 टिप्पणियां

 
carnoxen 1 시간 전

https://writings.hongminhee.org/2026/03/legal-vs-legitimate/

लाइसेंस विवाद को देखकर मुझे पिछली घटना याद आ रही है
 
unsure4000 3 시간 전

https://github.com/gitbutlerapp/grit/pull/837/changes/b1135eef106c71b0831d964c6506d8817e7a7201

काफ़ी घिनौना है। Grit-lib अभी भी mit क्यों है?
 
GN⁺ 4 시간 전
Hacker News की राय

  • “जब मैंने LLM द्वारा बनाए गए कोड की समीक्षा की, तो उसे library-योग्य और memory-safe बनाने के लिए काफी बड़े और व्यापक architectural बदलावों की ज़रूरत थी, इसलिए मैंने निष्कर्ष निकाला कि यह codebase GPL का अनुसरण करने वाला व्युत्पन्न कार्य नहीं है, और इसे MIT के तहत जारी करने का फैसला किया” — यह हिस्सा एक दिलचस्प विवाद का विषय लगता है

    • अगर किसी किताब का दूसरी भाषा में अनुवाद किया जाए, तो वह व्युत्पन्न कार्य होता है, और कंप्यूटर प्रोग्राम को किसी दूसरी programming language में अनुवाद करने पर भी वही बात लागू होनी चाहिए
      लेकिन अगर किताब का अनुवाद करते-करते उसकी कहानी और पात्रों के स्वभाव तक बदलने लगें, तो किस बिंदु पर वह व्युत्पन्न कार्य नहीं रह जाता — यह अस्पष्ट हो जाता है। मैं वकील नहीं हूँ, लेकिन रचनात्मक कार्यों से जुड़े case law में ऐसी सीमाओं पर काफी चर्चा हुई होगी
      आज की तरह जब “बौद्धिक संपदा” का दायरा लगातार फैलता जा रहा है, अगर यह मान लिया जाए कि LLM ने Git source code तक पहुँच बनाई थी, तो कानूनी स्थिति कमजोर लगती है
    • यहाँ शौकिया कानूनी विशेषज्ञों की बहुत-सी दिलचस्प व्याख्याएँ हैं, लेकिन मेरा रुख यह है कि reimplementation ने संरक्षित अभिव्यक्ति की नकल नहीं की
      Jplag के हिसाब से codebases के बीच अधिकतम समानता 1.8% से कम है, यह काम सद्भावना से किया गया था, और मुझे लगता है कि इससे पूरे Git ecosystem को भी लाभ होगा। बेशक, यह मानना होगा कि Grit वास्तव में उपयोगी साबित हो; और अभी यह दावा करने का समय नहीं है
      copyright के नज़रिए से इनमें सिर्फ पहला बिंदु ही प्रासंगिक है। Grit, Git-संगत व्यवहार का स्वतंत्र रूप से लिखा गया implementation है, और Git source code के साथ इसकी समानता इतनी कम है कि उसे नज़रअंदाज़ किया जा सकता है
      antirez ने स्थिति को अच्छी तरह समेटा है, और मैं मोटे तौर पर सहमत हूँ: https://antirez.com/news/162
      पिछले 20 वर्षों में Git और open source community में जो लोग मुझे जानते हैं और मेरे साथ काम कर चुके हैं, वे जानते होंगे कि मेरा इरादा योगदान, साझा करना, innovation और learning को बढ़ावा देना है। Git source के मुख्य लेखकों में से कई मेरे दोस्त हैं, और किसी से कुछ चुराने का मेरा ज़रा भी इरादा नहीं है। मैं बस शानदार ideas को और व्यापक रूप से उपयोगी बनाना चाहता हूँ
    • मुझे लगता है कि यह निष्कर्ष सीधा-सीधा गलत है। उम्मीद है कि मुकदमा दायर करने का अधिकार रखने वाला कोई व्यक्ति मुकदमा करे
    • संबंधित लेख: Malus – Clean Room as a Service
      https://news.ycombinator.com/item?id=47350424
      जैसे 1984 या Torment Nexus के मामले में होता है, किसी ने ऐसे विचार को, जिसे चेतावनी की तरह लेना चाहिए था, उपयोग निर्देशिका की तरह ले लिया
    • जो चीज़ आप नहीं जानते, उसे पहचान पाने की क्षमता जीवन और career में बेहद महत्वपूर्ण है। मैं 100% सहमत हूँ कि लेखक की समझ पर सवाल है
      उदाहरण के लिए, मान लीजिए किसी ने N64 के Goldeneye binary को निकाला, उसे LLM से disassemble कराया, और फिर किसी आधुनिक high-level language में दोबारा लिखवा दिया। क्या Nintendo कहेगा, “अच्छा, तुमने काफी मेहनत की, तो अब यह हमारे license से बाहर है”? बिल्कुल नहीं। यह बेतुकी बात है
      source code को खिलाकर किसी दूसरी भाषा में output बनवाना साफ़ तौर पर व्युत्पन्न कार्य है। यह समझने के लिए बौद्धिक संपदा का वकील होना ज़रूरी नहीं
      दूसरी तरफ, अगर Claude को सिर्फ documentation देकर एक compatible implementation बनाने को कहा जाए, तो क्या वह GPL के दायरे में आने वाला व्युत्पन्न कार्य होगा? शायद होगा, लेकिन अब मैं 100% आश्वस्त नहीं हूँ, और मैं ऐसा जोखिम नहीं लूँगा
      एक और विचार-प्रयोग के तौर पर, अगर कोई इस “MIT license” source tree को किसी दूसरे LLM में डालकर कहे कि इसे C में output करो, तो फिर license क्या होगा? SHA1 hash बनाना या command-line parser तैयार करना सीमित तरीकों से ही होता है, इसलिए नतीजा काफी मिलता-जुलता हो सकता है
      Oracle v. Google मामले में भी यह प्रमुख विवादों में से एक था। Google ने सफलतापूर्वक तर्क दिया था कि loops लिखने के तरीके सीमित होते हैं, इसलिए सिर्फ मूल के जैसे loop होने से अपने-आप copyright उल्लंघन साबित नहीं होता
      कुल मिलाकर, ऐसा रुख अपनाना सचमुच बहुत ज़्यादा खिंचाव वाला लगता है

  • समझ नहीं आ रहा। Gitoxide पहले से मौजूद है और शानदार है
    कुछ हिस्से गायब हो सकते हैं, लेकिन maintain हो रहे Gitoxide में ज़रूरी networking features को vibe coding से जोड़ना, पूरे Git को फिर से clone करने की कोशिश में tokens जलाने से आसान है
    Git को Rust additions चाहिए, और Gitoxide कई सालों से चल रहा प्रोजेक्ट है, इसलिए इसकी maintenance किसी ऐसे ad-hoc vibe clone से बेहतर होने की संभावना है जो बस “tests pass करते हैं” कहता हो
    अगर कोई उपयोगी use case हो तो मुझे vibe clone से अपने-आप में एतराज़ नहीं है, लेकिन इस मामले में कोई फ़ायदा नज़र नहीं आता। Git ऐसा tool है जिसे बहुत लोग पसंद करते हैं; यह vinext जैसी स्थिति नहीं है जो Next.js के vendor lock-in से नफ़रत के कारण आई हो
    management को भी समझना चाहिए कि “हमने लोगों के प्रिय software की अपनी copy बनाने के लिए tokens पर हज़ारों डॉलर जला दिए” — copyright और license बहस को अलग रख दें तब भी — community में सकारात्मक रूप से लिया जाने वाला काम नहीं है
    जिस काम को लोग पसंद करते हों, उसका बिना किसी फ़ायदे के copy बनते देखना अच्छा नहीं लगता। अब हम उस चरण से आगे निकल चुके हैं जहाँ बात सिर्फ “देखें AI कहाँ तक जा सकता है” वाले experiment की हो

    • जैसा बताया गया, हम भी Gitoxide project में शामिल हैं, और Byron भी हमारी टीम का सदस्य है। community के बड़े प्रयासों से हम अच्छी तरह वाक़िफ़ हैं, और इस साल Git Merge conference के co-host भी हैं
      हाल में Gitoxide में vibe loop के ज़रिए और Git functionality जोड़ने की एक कोशिश हुई है, जो दिलचस्प है: https://github.com/GitoxideLabs/gitoxide/pull/2538
      फिर भी, मुझे लगता है कि थोड़ा और काम होने पर यह project क़ीमती साबित हो सकता है। यह announcement final product नहीं, सिर्फ एक milestone है। project के बीच तक भी हमें यक़ीन नहीं था कि यह संभव होगा या नहीं
      हमने बहुत कुछ सीखा है और आगे भी बहुत कुछ सीखेंगे, लेकिन Gix — जो एक high-quality, hand-crafted, strongly opinionated partial Git library है — और Grit — जो vibe से बनी लगभग complete implementation वाली लेकिन कुछ हद तक rough LLM Git library है — दोनों के उपयोगी applications हो सकते हैं। फ़िलहाल दोनों options को explore और invest करने लायक मानता हूँ
      और मैं वही management व्यक्ति हूँ जो इसमें शामिल है, और पिछले कई सालों में Git community के लिए काफ़ी काम कर चुका हूँ। मेरा “अपनी copy” रखने की कोशिश करना बेतुका है
      मैंने Pro Git किताब(https://git-scm.com/book/en/v2) और उससे पहले Git community book(https://schacon.github.io/gitbook/index.html) लिखीं और उन्हें open source में जारी किया, official Git website(https://git-scm.com) बनाई, GitHub का co-founder रहा जो दुनिया भर के लगभग सारे open source को host करता है, और लगभग 20 साल से Git ecosystem को बढ़ावा और support देता आया हूँ
      15 साल पहले मैंने libgit2 development को फिर से शुरू कराया और उसे fund किया; इसे भी कोई यह कहकर पेश कर सकता है कि management Git की “अपनी copy” ज़्यादा permissive license में चाहता था, लेकिन ऐसा दावा भी उतना ही हास्यास्पद है
    • मेरी जानकारी में GitButler ने अभी gitoxide maintainer को hire किया है या उसके साथ काम कर रहा है। इसलिए उन्हें यह ज़रूर पता होगा
      शायद उन्होंने तय किया होगा कि gitoxide उनके use case के लिए काफ़ी नहीं है, या उसे extend/improve करने की लागत बहुत ज़्यादा है

  • memory safety जैसी चीज़ें अच्छी हैं, लेकिन सच कहूँ तो समझ नहीं आता कि यह किस use case के लिए है
    क्या यह agentic development दिखाने के लिए है? 10 साल से ज़्यादा समय से Git इस्तेमाल कर रहा हूँ और memory overflow वगैरह की वजह से कभी fail नहीं हुआ। कुछ software ऐसे होते हैं जिन्हें “जैसे हैं वैसे ही काफ़ी अच्छे” कहा जा सकता है, और मुझे पूरा यक़ीन है कि Git उनमें आता है
    20 से ज़्यादा developers और बहुत सारे binary artifacts संभालने वाली team में भी हमने Git की limits से बहुत कम टक्कर खाई है। अगर आप सच में Git की limits को push कर रहे हैं, तो शायद Git से बाहर जाना पड़े — Rust rewrite से कोई मदद नहीं मिलेगी। इसलिए फिर पूछना चाहता हूँ, क्यों?

    • लेख में इसका जवाब पहले ही था, लेकिन Git के पास linkable library नहीं है, और लंबे समय से नहीं रही
      कोई छोटा-सा काम करने के लिए भी process को fork/exec करना पड़ता है और stdin/stdout से बात करनी पड़ती है। नहीं तो सब कुछ पूरी तरह reimplement करना पड़ता है और सारे edge cases संभालने पड़ते हैं
      उदाहरण के लिए, एक object पढ़ना loose object होने पर आसान है, लेकिन अगर वह packfile के अंदर हो तो काफ़ी मुश्किल हो जाता है। reference पढ़ना, यानी यह देखना कि branch किस SHA की ओर इशारा कर रही है, वह भी loose file, packfile, या reftable में से कुछ भी हो सकता है
      इसे CLI purpose के लिए कोई इस्तेमाल नहीं करेगा। stable हो जाने पर भी यह लगभग निश्चित रूप से हमेशा धीमा होगा और हर मायने में बदतर होगा। अभी तो यह stable भी नहीं है
      आप libgit2 या Gitoxide इस्तेमाल कर सकते हैं, और दोनों ही ऐसे projects हैं जिन्हें शुरू कराने में मैंने मदद की थी या जिन्हें GitButler अभी आगे बढ़ाने में मदद कर रहा है। वे लगभग हर मामले में तेज़ और बेहतर हैं, लेकिन feature-complete नहीं हैं
      यह Git इस्तेमाल करने वालों के लिए नहीं, बल्कि उन लोगों के लिए है जो Git के कुछ हिस्सों का उपयोग करने वाले tools बनाना चाहते हैं
    • license laundering है
    • नहीं तो फिर Git license को कैसे launder करेंगे, और बाद में bait and switch की तैयारी कैसे करेंगे?

  • अब लगता है कि software licenses का कोई मतलब नहीं बचा, क्योंकि कोई भी बस यह तय कर सकता है कि उसका LLM clone derivative work नहीं है

    • अभी कुछ लोग ऐसे बर्ताव कर रहे हैं जैसे किसी project को दूसरी language में translate करके उसका license बदल देना ठीक हो
      हाल में Casey Muratori ने इसी संदर्भ में कहा कि Microsoft का AI push शायद इस बात से जुड़ा हो सकता है कि उनके पास पुराना और विशाल codebase है। पुरानी बड़ी software कंपनियों को model training में फ़ायदा है, और वे अपनी intellectual property से अतिरिक्त value दे सकती हैं
      लेकिन अब वही intellectual property model के अंदर जा सकती है और किसी के लिए भी accessible हो सकती है। अगर वे सच में अपने intellectual property पर model train करते हैं, तो कोई भी उसका API implement करके उस पर GPL license लगा सकता है
      उस बिंदु के बाद चीज़ें सच में दिलचस्प हो जाएँगी
    • क्योंकि लगभग सभी FOSS copyright holders violators पर मुक़दमा नहीं करते, licenses का मतलब पहले से ही काफ़ी कमज़ोर था

  • यह GPL कोड की चोरी है और license laundering है
    मैं समझ सकता हूँ कि test suite से उल्टा काम किया जाए, लेकिन यहाँ तो सचमुच मूल source पढ़ा गया है: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#source-of-truth
    LLM उपयोगकर्ता मानो किसी दूसरी दुनिया में रहते हैं जहाँ जो चीज़ें स्थिर नहीं हैं, उन्हें सब चुरा लेना और फिर उसे अपना काम बताना ठीक है

    • मैं इसे अलग तरह से देखता हूँ। इसे ऐसे समझिए कि यही कोड मैंने खुद लिखा होता। आप docs देखते हैं, tests देखते हैं, source देखते हैं, और interoperable लेकिन approach में बहुत अलग implementation बनाते हैं
      उदाहरण के लिए, जब मैं GitButler में SSH commit signing को सही तरह से चलाने की कोशिश कर रहा था, तब मैंने बिल्कुल यही किया था: https://blog.gitbutler.com/signing-commits-in-git-explained
      जैसा कि उस लेख में दिखता है, canonical behavior समझने के लिए मैंने C source को गहराई से देखा, फिर वही काम Rust में implement किया, लेकिन source code कॉपी नहीं किया
      Grit के Rust source और Git source के बीच कुछ समानताएँ हैं, लेकिन ज़्यादातर वे time·format handling या packfile parsing के लिए ज़रूरी byte offsets जैसी चीज़ें हैं। मुझे इसमें सीधी code copying नहीं दिखती
      इसे reentrant, memory-safe, और library-centric codebase बनाने के लिए approach ही इतनी अलग है कि copying आम तौर पर उपयोगी नहीं होती
      लेकिन packfile या reftable के binary formats ठीक से documented नहीं हैं, इसलिए कोई भी उन्हें सिर्फ अनुमान से सही नहीं कर सकता। यह मैं अच्छी तरह जानता हूँ, क्योंकि शायद मैं उन गिने-चुने लोगों में से हूँ जिन्होंने packfile binary format को document करने की कोशिश की है: https://schacon.github.io/gitbook/7_the_packfile.html
      source पढ़ना मजबूरी है। अगर इस परिभाषा को मानें, तो libgit2, Gitoxide, और Git की बाकी सभी reimplementations भी technical spec की पुष्टि करने के लिए Git source को देखती रही हैं, तो वे सब भी “license laundering” ठहरेंगी
      अगर आपको Grit में कहीं साफ़ तौर पर line-by-line कॉपी किया गया code मिले, तो बताइए। मैं उसे बदल दूँगा। लेकिन Git source ही Git spec है, और LLM हो या न हो, compatibility बनाने के लिए हर reimplementation को यह तरीका अपनाना पड़ता है
    • यह डरावना है कि यह किसी बड़े समूह को स्वीकार्य लग सकता है
      मुझे समझ नहीं आता कि दूसरे intellectual property holders — जैसे क़ीमती proprietary software, music, films, या यहाँ तक कि खुद LLMs रखने वाले लोग — यह क्यों नहीं सोचते कि अगली बारी उनकी है
      intellectual property का यह क्षरण रुकना चाहिए। नहीं तो बौद्धिक श्रम करने वाला हर व्यक्ति पूरी तरह बर्बाद हो जाएगा। अगर यह सिर्फ FOSS लोगों तक सीमित होता, तो भी मैं इस बात से चिंतित रहता कि उन्हें बाकी सबके साथ बहा दिया जाएगा, लेकिन यह साफ़ तौर पर एक व्यापक समस्या है
    • पक्का नहीं, लेकिन क्या पूरा मूल source code training data में भी शामिल नहीं रहा होगा?

  • मैंने पहले भी यह उपमा इस्तेमाल की है कि “यह जिन्न से मन्नत माँगने जैसा है। आपको बुनियादी नियम बहुत स्पष्ट रखने पड़ते हैं”
    पहले यह मुझे golem जैसा ज़्यादा लगता था, लेकिन Fable के sabotage mode https://jonready.com/blog/posts/claude-fable5-is-allowed-to-sabotage-your-app-if-youre-a-competitor.html की वजह से अब यह निश्चित रूप से जिन्न के ज़्यादा करीब लगता है
    पहले मैं कहता था, “model आपको वह नहीं देता जो आप चाहते हैं, बल्कि वह देता है जो आपने माँगा है।” अब Fable में तो वह वह भी नहीं देता जो आप चाहते हैं, इसलिए अब क्या कहूँ, समझ नहीं आता

  • अगर बात experiment की है, तो मुझे तो उलटी दिशा ज़्यादा दिलचस्प लगती है। ऐसे projects आम तौर पर “performance” के लिए rewrite किए जाते दिखते हैं, और शायद इसलिए कि AI की वजह से लागत कम हो गई है
    मैं Quake III को Python में port करते हुए, या Kubernetes को Perl में, या यहाँ तक कि Rails को Python में ले जाते हुए देखना चाहूँगा — अजीब लेकिन मज़ेदार तरह के काम

    • Quake III को Python में शायद किया जा सकता है
      मुझे याद है कि Natural Selection 2 का अधिकांश हिस्सा Lua में था, और वह भी 10 साल से ज़्यादा पहले की बात है
    • कहा तो जा रहा है कि यह rewrite “performance” के लिए है, लेकिन वास्तव में इसकी performance कहीं बदतर है
      नतीजा यह है कि 10,000~15,000 डॉलर में एक धीमा, कम-tested, और अधूरा Git implementation बना है
      इस प्रक्रिया में काफ़ी human time भी बर्बाद हुई
      कहीं और यह भी सुनने में आया था कि कोई समूह पहले से Rust port पर काम कर रहा था। अगर इतनी रकम और software development resources वहाँ लगाए जाते, तो कितना कुछ किया जा सकता था?
      ऐसा लगता है कि AI बिना पर्याप्त thorough testing के भी किसी चीज़ को port कर सकता है — यह बात अब तक साबित हो चुकी है। अब इस तरह के काम में मुझे पहले से कम value दिखती है। लेखक के लिए यह मज़ेदार रहा होगा, लेकिन दूसरों के लिए यह कैसे मददगार है, समझ नहीं आता
    • अगर सच में performance वजह होती, तो वे मूल license का ही उपयोग करते। लेकिन ऐसा नहीं किया गया
      पूरी RiiR movement का मकसद बहुत साफ़ तौर पर GPL जैसे user-friendly license से बाहर निकलना लगता है

  • “यह काफ़ी दिलचस्प प्रयोग है, और मुझे लगता है कि इसे पूरे community के लिए सच में उपयोगी किसी चीज़ में निखारा जा सकता है” — इस हिस्से से सहमत हूँ। प्रयोग तो हम सब मिलकर एंजॉय कर सकते हैं
    लेकिन “क्योंकि यह linkable और reentrant library नहीं है, बल्कि अधिक सरल commands को जोड़ने वाली Unix philosophy पर आधारित है, इसलिए इसे long-running process में हर बार fork/exec overhead के बिना इस्तेमाल करना मुश्किल है” — इस हिस्से पर मेरा दार्शनिक मतभेद है
    पूरे लेख में “क्यों” बताने वाली यही एकमात्र जगह है, और Unix शैली को एक feature माना जा सकता है, बल्कि आज के समय में यह और भी महत्वपूर्ण हो सकता है: https://aperocky.com/blog/post.html?slug=unix-philosophy-agentic

    • सुविधा के लिए quote को थोड़ा काटा है
      “क्योंकि यह linkable और reentrant library नहीं है, बल्कि अधिक सरल commands को जोड़ने वाली ‘Unix’ philosophy पर आधारित है, इसलिए इसे सभी कामों के लिए fork/exec overhead के बिना long-running process में इस्तेमाल करना मुश्किल है” — पूरा वाक्य ही मुख्य बात है
    • क्या Git पहले से ही libgit के ऊपर बना interface नहीं है? फ़र्क क्या है, समझ नहीं आता

  • 15 साल से ज़्यादा समय से Git इस्तेमाल कर रहा हूँ और एक बार भी crash नहीं देखा। आख़िर यह किस समस्या को हल कर रहा है?

    • इसका लक्ष्य एक feature-complete, reentrant, linkable library बनाना है। ऐसे सवालों में अक्सर लेख पढ़ना मददगार होता है
    • जो चीज़ हल की जा रही है, वह उपयोगकर्ता के लिए फ़ायदेमंद license यानी GPL है
    • सालों में crashes काफ़ी देखे हैं। ज़्यादातर किसी private repository में gc और pruning कुछ समय तक अप्रत्याशित termination का कारण बने
      फिर भी कुल मिलाकर इसकी stability सच में शानदार रही है। बस इस खास rewrite के “क्यों?” का जवाब मैं नहीं दे सकता
    • एक तरह की LLM psychosis की समस्या है, जिसमें लोग मान लेते हैं कि LLM की वजह से उन्हें सुपरपावर मिल गई है
      ये लोग पूरी तरह अनजाने में, भोलेपन से काम शुरू कर देते हैं और अपने दम पर सोचने की क्षमता खो चुके हैं। उनकी जगह सोचने वाला LLM यह नहीं कहता कि “X करना बुरा विचार है।” LLM का अस्तित्व उसके मालिक के लिए जितना संभव हो उतने tokens पैदा करने के लिए है

  • यह GitHub के एक cofounder की तरफ़ से आया है, यानी बहुत संभव है कि वह ठीक-ठीक जानता हो कि GPL किस लिए है
    कानूनी फ़ायदे-नुकसान जो भी हों, GPL3 project की पूरी test suite पर बनाना और फिर उसे MIT के तहत relicense करना मूल लेखकों के प्रति अच्छी नीयत से किया गया काम नहीं है
    यह सच में घिनौना लगता है और इससे GitButler को पूरी तरह avoid करने का मन होता है

    • यह ऐसा सुनाई देता है जैसे आप GPL license की test suite को उस खास उद्देश्य के लिए इस्तेमाल करने की आज़ादी में विश्वास नहीं करते जिसे GPL स्पष्ट रूप से अनुमति देता है
      license चुन लेने के बाद, सिर्फ़ इसलिए कि बाद में आपको पसंद नहीं आया, आप उस पर अतिरिक्त शर्तें नहीं जोड़ सकते। यह वही चीज़ है जिसकी GPL license स्पष्ट रूप से अनुमति नहीं देता