Ask HN: क्या हम version control के लिए Git से बेहतर कर सकते हैं?
एक version control system के रूप में Git की dominance व्यापक रूप से स्वीकार की जाती है, लेकिन कई engineers मानते हैं कि यह आदर्श से काफी दूर है, खासकर usability, बड़े binary assets को संभालने, और विशाल monorepos के समर्थन के मामले में। टिप्पणीकार Fossil, Mercurial, Perforce, Pijul, Jujutsu, और Sapling जैसे alternatives, साथ ही Git के ऊपर बनी UI layers और tools की ओर इशारा करते हैं, यह दिखाने के लिए कि बेहतर workflows और models संभव हैं। प्रचलित विचार यह है कि network effects और GitHub का ecosystem निकट भविष्य में outright replacement को असंभव बनाते हैं, इसलिए अधिकांश व्यावहारिक innovation बेहतर interfaces, smarter merges, और non-code assets के लिए specialized systems पर केंद्रित है, न कि Git को पूरी तरह छोड़ने पर।
Git पर समग्र भावना
- बहुत से लोग Git को “काफी अच्छा” मानते हैं और इसके लंबे समय तक dominant रहने की संभावना देखते हैं, आदर्श होने की वजह से नहीं, बल्कि इसकी ubiquity और ecosystem की वजह से।
- दूसरे लोग कहते हैं कि यह बिल्कुल भी solved problem नहीं है: confusing UI, खराब defaults, और कुछ वास्तविक architectural limitations मौजूद हैं।
- कई टिप्पणियाँ बताती हैं कि Git ने पहले के खराब systems (RCS/CVS/SVN) को बदला और बड़ी समस्याएँ हल कीं, लेकिन अब यह खुद पुराना लगता है।
UX, mental model, और सीखने की कठिनाई
- confusing concepts और commands पर बार-बार शिकायतें: commit बनाम push बनाम pull बनाम fetch, staging area, rebase, reflog, आदि।
- कुछ लोग एक सरल “easy mode” चाहते हैं जिसमें छोटा, सुरक्षित command set हो (“save / update” शैली) और advanced operations के लिए “expert mode” हो।
- “professionals के लिए tools, complexity ठीक है” और “खराब UX समय बर्बाद करता है और उचित नहीं है” के बीच तनाव है।
- GUIs और higher-level tools (IDEs, desktop apps, TUI frontends, wrappers जैसे Graphite, Magit, आदि) को Git को संभालने के प्रभावी तरीके माना जाता है।
तकनीकी और architectural pain points
- बड़े files और binary assets: Git LFS को clunky और fragile माना जाता है; game dev और CAD workflows अक्सर Perforce या SVN को पसंद करते हैं।
- बहुत बड़े monorepos: status scans, history size, और कई files के कारण performance issues; workarounds में virtual file systems, sparse/partial clones, और vendor-specific tools शामिल हैं।
- Conflict resolution: मौजूदा merge algorithms को “fast but dumb” माना जाता है; conflicts का limited modeling (कोई first-class “conflicted state” नहीं), hard renames, और semantic understanding की कमी।
- Storage model: snapshot-of-blobs बनाम patch-based; कुछ लोगों का तर्क है कि patch-based systems (Darcs, Pijul) बेहतर merges और history reasoning सक्षम बनाते हैं।
Alternatives और नए systems
- अक्सर उल्लेखित: Fossil (integrated tickets/wiki, immutable history), Mercurial और derivatives (Sapling, internal Google systems), Darcs, Pijul, Jujutsu, Perforce, और domain-specific tools (जैसे बड़े AI datasets के लिए Oxen)।
- कुछ नए tools Git-compatible storage/protocol स्तर पर रहते हुए नए UIs या semantics देते हैं, और इन्हें clean break से अधिक adoptable माना जाता है।
Hosting, centralization, और network effects
- Git की dominance GitHub और समान forges से गहराई से जुड़ी है; discoverability और contributions GitHub के बाहर प्रभावित होते हैं।
- GitLab, Forgejo/Gitea, SourceHut, Codeberg, और Fossil hosting जैसे alternatives मौजूद हैं, लेकिन network effects के सामने संघर्ष करते हैं।
- forges के बीच federation को lock-in कम करने का एक संभावित तरीका बताया गया है।
भविष्य की दिशाएँ
- उठाए गए विचार: semantic diffs/merges, AST-based code storage, branch history को first-class object के रूप में, बेहतर physical-history tracking, editor-integrated move tracking, और अधिक centralized-first workflows।
- यह स्पष्ट नहीं है कि इनमें से कोई Git को विस्थापित करने के लिए पर्याप्त momentum हासिल करेगा या नहीं; निकट भविष्य में Git के ऊपर improvements की layering को सबसे यथार्थवादी रास्ता माना जाता है।