बीस साल कुछ भी नहीं हैं

इम्प्लीमेंटेशन भाषाएँ और “written in Rust”

• प्रोजेक्ट्स के “written in Rust” के रूप में विज्ञापन करने के कारणों पर बार-बार बहस।
• समर्थक कहते हैं कि भाषा का चुनाव यह संकेत देता है:
  • GC के बिना मेमोरी सेफ्टी और स्पीड।
  • स्थिर, self-contained बाइनरीज़ और सुचारू टूलिंग।
  • एक ऐसी डेवलपर संस्कृति जो correctness और performance की परवाह करती है।
• संदेहवादी इसे कमजोर मार्केटिंग मानते हैं: अगर “written in Rust” ही हेडलाइन है, तो शायद अलग दिखाने के लिए ज़्यादा कुछ नहीं है।
• कुछ लोग नोट करते हैं कि भाषा प्रोजेक्ट की शैली और ecosystem fit का पूर्वानुमान देती है (जैसे Rust/Go जानने पर योगदान करना Python की तुलना में आसान)।
• Python/JS पर performance और long-term stability को लेकर आलोचनाएँ; Go को distribution के मामले में Rust जैसा, लेकिन type/ownership guarantees के मामले में नहीं, बताया गया।

Pijul, patch-based VCS, और CRDT विचार

• Pijul और Fossil को Git के सच्चे विकल्पों के रूप में रेखांकित किया गया, जिनके डिज़ाइन अलग हैं; jj और Sapling को अधिकतर बेहतर Git/Mercurial interfaces माना गया।
• Pijul के लेखक समझाते हैं:
  • डिज़ाइन patch/CRDT-based है; conflicts मॉडल का हिस्सा हैं।
  • डेटा संरचनाएँ “theorists की तरह” डिज़ाइन की गईं, फिर optimize की गईं।
  • एक custom Rust key–value store (Sanakirja) तेज, generic, mmap-friendly storage और efficient forking सक्षम करता है, और उनके benchmarks में LMDB से बेहतर प्रदर्शन करता है।
  • कम-स्तरीय नियंत्रण के लिए Rust को व्यावहारिक रूप से चुना गया, बिना C++ की debugging परेशानी के; आज भाषा के evolution को देखते हुए शायद Zig चुनते।
• कुछ लोगों का तर्क है कि patch-based VCS, snapshot-based Git की तुलना में बड़े repos, conflicts, blames, और binary files के लिए तेज़ हो सकता है।

Git की ताकत, कमजोरियाँ, और workflows

• व्यापक रूप से इसकी प्रशंसा की गई:
  • पुराने टूल्स की तुलना में speed।
  • Distributed workflow और offline commits।
  • लचीलापन और शक्तिशाली data model।
• आलोचनाएँ:
  • CLI UX भ्रमित करने वाली है; concepts internal implementation को उजागर कर देते हैं।
  • Rebase, history rewriting, और stacked-commit workflows कठिन हैं; Gerrit/Graphite/jj जैसे टूल इन्हें कम करने की कोशिश करते हैं।
  • Git snapshots रखता है, explicit change history नहीं; file renames/splits और बड़े refactors को track करना कठिन है।
  • Empty directories नहीं; file splits/merges और semantic moves का इतिहास कमजोर है।
  • कुछ लोगों को Git LFS नाज़ुक और operationally awkward लगा, और extra server components की ज़रूरत पड़ती है।

Centralization, history size, और partial clones

• इस पर बहस कि क्या full-history local clones 20 साल पहले “unthinkable” थे; कुछ लोग CVS/SVN के साथ local scripts और पर्याप्त बड़े disks को याद करते हैं, जबकि अन्य उस समय की network और storage सीमाओं पर ज़ोर देते हैं।
• यह बिंदु कि DVCS का एक व्यावहारिक cap है: repo history सबसे छोटे dev laptop में समानी चाहिए।
• कुछ का तर्क है कि अधिकांश संगठन de facto centralized हैं और hierarchical/subordinate clones से लाभ उठा सकते हैं: partial history, partial trees, लेकिन फिर भी local branching और commits।
• नए Git partial clone और sparse-checkout फीचर्स को आंशिक समाधान के रूप में उल्लेखित किया गया।

Binary assets और non-text projects

• Git का text-centric model अधिकांश software के लिए अच्छा काम करता है, लेकिन:
  • Games, chip design, और media pipelines बड़े binaries के कारण अभी भी Perforce या SVN को तरजीह देते हैं।
  • Git LFS को buggy, operationally complex, और extra server components की मांग करने वाला बताया गया।
  • ऐसे VCS की इच्छा जो binary formats को समझे (जैसे images के लिए semantic diffs) और बड़े file storage को मूल रूप से संभाले; Pijul native binary support का दावा करता है।

Semantic, AST-aware, और CRDT-based भविष्य

• कई commenters सुझाव देते हैं:
  • raw text के बजाय ASTs या domain-specific structures पर version control।
  • बेहतर diffs/conflicts जो moves, renames, refactors को समझें।
• एक प्रस्ताव: Git का उत्तराधिकारी जो character-level CRDT histories store करे, real-time collaboration और semantic commits का समर्थन करे; खुले मुद्दों में conflict surfacing और data deletion (secrets) शामिल हैं।
• अन्य लोगों का तर्क है कि इतनी granularता noise और complexity बढ़ा सकती है; commits को human-chosen checkpoints के रूप में बनाए रखना मूल्यवान है।

ऐतिहासिक टूल्स और दृष्टिकोण

• VSS, ClearCase, Perforce, CVS, SVN, RCS, BitKeeper, और ad hoc zip/tar “versioning” की विस्तृत यादें।
• Lock-based centralized systems (VSS, कुछ ClearCase/Perforce setups) को दर्दनाक याद किया गया, लेकिन कभी “professional” माना जाता था; open-source workflows with CVS/SVN को कई enterprises से आगे माना गया।
• समग्र भावना यह थी कि हर पीढ़ी ने अपने टूल्स को अच्छा समझा, जब तक कि अगला बड़ा कदम (SVN, फिर Git/DVCS) उनकी सीमाएँ सामने नहीं ले आया।

क्या कुछ Git को बदल पाएगा?

• कुछ लोगों का मानना है कि Git एक evolutionary plateau है; successors को चाहिए:
  • पूर्ण Git compatibility और मौजूदा repos पर पारदर्शी उपयोग।
  • सरल UX और बेहतर semantics (renames, AST-aware ops, stacked commits)।
  • बड़े repos और binaries का बेहतर handling।
• अन्य लोग अंततः displacement की उम्मीद करते हैं, VCS churn के लंबे इतिहास का हवाला देते हुए; फिर भी Git के network effects और “good enough” स्थिति के कारण वह लंबे समय तक dominant रह सकता है।