Grit: एजेंटों के साथ Rust में Git का पुनर्लेखन

मूल लेख ↗ Hacker News चर्चा ↗

प्रेरणा और घोषित लक्ष्य

  • परियोजना Git का ज़मीन से किया गया Rust कार्यान्वयन है, जिसे बड़े हिस्से में LLM “agents” चला रहे हैं।
  • मुख्य घोषित लक्ष्य: एक feature-complete, reentrant, linkable Git library (खासकर networking/credentials) बनाना, ताकि Git-आधारित GUIs और वैकल्पिक VCS frontends जैसे टूल्स इसका उपयोग कर सकें।
  • इस बात पर ज़ोर कि इसका उद्देश्य canonical Git को CLI के रूप में बदलना नहीं है, बल्कि इसे एक library के रूप में सेवा देना है, जहाँ Git/libgit2/gitoxide अधूरे हों या उपयुक्त न हों।

तकनीकी स्थिति और तुलना

  • बताया गया है कि यह upstream Git test suite के लगभग 99.3% परीक्षण पास करता है; शेष परीक्षण स्पष्ट रूप से skip किए गए हैं (email, i18n, SVN/Perforce importers, कुछ bitmap/midx, आदि)।
  • इसके अपने लेखक ने स्वीकार किया है कि यह वर्तमान में Git की तुलना में धीमा, भारी, कम scalable, और संभवतः buggy है; canonical Git को “linkable library” होने को छोड़कर हर तरह से बेहतर कहा गया है।
  • Binary, Git की तुलना में काफ़ी बड़ा है, जिसका बड़ा कारण Rust ecosystem है (CLI parsing, dependencies)। Library subset छोटा है, लेकिन फिर भी गैर-तुच्छ है।
  • बार-बार इसकी तुलना gitoxide और libgit2 से की गई, जो पहले से libraries प्रदान करते हैं लेकिन पूर्ण feature/networking parity नहीं रखते।

उपयोग-परिदृश्य और रुचि

  • संभावित उपयोग: Rust apps में embedded Git networking/credentials, custom Git servers/clients, browser/edge environments के लिए WASM builds।
  • कुछ लोग इसे “agentic” development और बड़े पैमाने पर LLM-assisted ports के लिए एक दिलचस्प experiment या proof-of-concept मानते हैं।
  • अन्य लोग सवाल उठाते हैं कि gitoxide/libgit2 को विस्तारित करने से जो हासिल हो सकता है, उससे आगे कोई व्यावहारिक niche है भी या नहीं।

लागत, ROI, और व्यवहारिकता

  • token खर्च लगभग $8k–$15k आंका गया।
  • कई टिप्पणीकार इसे खराब ROI मानते हैं: धीमा, अधूरा, वास्तविक दुनिया में अप्रयुक्त tool बनाम battle-tested Git, और साथ में पहले से मौजूद Rust alternatives।
  • कुछ का तर्क है कि यह मुख्यतः दिखाता है कि AI “tests pass” करवा सकता है, लेकिन वास्तविक उपयोग में robustness सिद्ध नहीं करता।

लाइसेंसिंग, कॉपीराइट, और नैतिकता

  • प्रमुख विवाद: मूल Git GPL है; यह परियोजना MIT के तहत जारी की गई है।
  • LLM agents को Git का source और tests “source of truth” के रूप में दिए गए थे, केवल black-box behavior नहीं। आलोचक इसे plagiarism, “license washing,” या copyleft codebase का “Rustwashing” कहते हैं।
  • लंबी, मिश्रित कानूनी बहस:
    • एक पक्ष: Rust में अलग संरचना के साथ पुनर्लेखन, और कम similarity metrics, इसे derivative work नहीं बनाते; Git के tests को behavioral spec के रूप में इस्तेमाल करना अनुमति-योग्य है; GPL स्वतंत्र कार्यान्वयनों को स्वतः प्रभावित नहीं करता।
    • दूसरा पक्ष: GPL code को सीधे LLM में डालकर functional रूप से समकक्ष implementation माँगना translation/adaptation जैसा है, इसलिए परिणाम को GPL inherit करना चाहिए; LLM को compiler/transpiler जैसे transformation tool की तरह देखा जाना चाहिए, न कि किसी जादुई license eraser की तरह।
    • अतिरिक्त तर्क कि क्या test suites स्वयं outputs को derivative बना सकते हैं, और क्या LLM outputs पर copyright लागू भी होता है या नहीं।
  • नैतिक रूप से, कई लोग इसे GPL की मंशा को कमज़ोर करने और समुदाय के मूल्य को एक permissive, अधिक corporate-friendly license में खींच लेने जैसा मानते हैं, भले ही यह कानूनी रूप से तर्कसंगत हो सकता है।

Rust पुनर्लेखन और LLM उपयोग

  • “rewrite in Rust” संस्कृति को लेकर व्यापक निराशा, विशेषकर GPL projects को MIT/Apache में बदलने के संदर्भ में।
  • कुछ लोग Rust को critical infrastructure (जैसे Git, nginx) में memory safety के लिए मूल्यवान मानते हैं; अन्य का तर्क है कि मुख्य समस्याएँ logic की हैं, memory की नहीं, और AI-driven rewrites लाभ से अधिक bugs ला सकती हैं।
  • security-sensitive components में “vibecoded” या “slop” LLM-generated code के खिलाफ़ कड़ा विरोध।
  • कुछ लोग experimental, agentic approach और ports चलाने के लिए LLMs के उपयोग के प्रति उत्साही हैं, लेकिन कई लोगों को लगता है कि novelty अब कम हो गई है और ऐसे projects को अब स्पष्ट, user-facing लाभ दिखाने चाहिए।

प्रस्तावित वैकल्पिक दृष्टिकोण

  • संपूर्ण पुनर्लेखन के बजाय:
    • gitoxide या libgit2 को विस्तारित करना, खासकर networking/credentials, संभवतः targeted LLM सहायता के साथ।
    • पहले Git के code/tests/docs से behavioral spec निकालकर उसे formalize करना, फिर उस “contract” से reimplement करना ताकि test-hacking से बचा जा सके और लागत कम हो।
    • Git के storage model के ऊपर नए tools या abstractions पर ध्यान देना, उसकी पूरी implementation की नकल करने के बजाय।