Mozilla में मैंने एक तरह से Mercurial को खत्म कर दिया
Mozilla का Mercurial से Git और GitHub की ओर जाना एक बड़े बदलाव का हिस्सा बताया गया है, जहाँ Mercurial, अपनी ज़्यादा friendly CLI और मजबूत सुविधाओं के बावजूद, Git के network effects, tooling ecosystem, और Microsoft, Meta, तथा Google जैसी दिग्गज कंपनियों के समर्थन के आगे पीछे छूट गया। टिप्पणीकार यह भी चर्चा करते हैं कि Bitbucket जैसे शुरुआती Mercurial hosts ने इसे क्यों छोड़ दिया, बड़ी कंपनियाँ अब Sapling, jj, Perforce, Piper जैसे custom systems को Git-like models के इर्द-गिर्द कैसे बनाती हैं, और कई डेवलपर्स को अभी भी Git की UX Mercurial की तुलना में confusing क्यों लगती है। यह thread GitHub की कमजोर code review ergonomics और Mozilla का Microsoft-owned platform पर निर्भर होना—जो lock-in risk पैदा करता है—को खुले स्रोत सहयोग के dominant infrastructure के साथ align करने के व्यावहारिक लाभों के मुकाबले रखता है।
Mercurial का पतन और नेटवर्क प्रभाव
- कई लोग Mercurial को व्यावहारिक रूप से “खत्म” मानते हैं: Bitbucket ने hg छोड़ दिया, बड़े होस्ट Git-only हो गए, और Mercurial का नया अपनाना बहुत कम है।
- दूसरे लोग इसका विरोध करते हैं कि Mercurial अभी भी maintained है, Python 3 पर चलता है, इसमें Rust components हैं, और Changeset Evolution जैसी सुविधाएँ मिलती हैं।
- आम सहमति: Git ने बड़े पैमाने पर नेटवर्क प्रभावों के कारण जीत हासिल की (Linux kernel, GitHub, tooling ecosystem)। एक बार लोग Git सीख लेते हैं, तो hg बेहतर होने पर भी बदलना कम ROI वाला लगता है।
Hosting platforms और missing “HgHub”
- Bitbucket को बार-बार de facto “hghub” कहा जाता है जिसने पहले hg-only शुरुआत की, फिर Git जोड़ा, और फिर hg हटा दिया।
- कुछ लोग Mercurial हटाने को दूरदर्शिता की कमी मानते हैं; दूसरे तर्क देते हैं कि hg का उपयोग नए users में 1% से भी नीचे आ गया था और दो VCS systems को support करना उचित नहीं था।
- SourceHut और Heptapod को बाकी बचे Mercurial-friendly hosts के रूप में उल्लेख किया गया है।
बड़ी कंपनियों के VCS stacks (Meta, Google, Microsoft)
- Meta ने ऐतिहासिक रूप से Mercurial को बड़े पैमाने पर इस्तेमाल किया; अब वह Sapling को expose करता है, जो Mercurial-derived system है और Git compatibility रखता है। अंदरूनी तौर पर लोग अभी भी
hg-style commands का उपयोग करते हैं, लेकिन open-source Sapling अलग दिशा में बढ़ चुका है और अब ज़्यादा अपना खुद का VCS है। - Sapling की Git interop को उपयोगी बताया गया है, लेकिन अभी भी rough है (LFS issues, force-push friction, large repo edge cases)।
- Google ने अपने monorepo (Piper) के लिए Mercurial-based client का front-end बनाया क्योंकि hg के पास real wire protocol था; इसे
jj(Jujutsu) से बदलने पर काम चल रहा है, जो hg से UX ideas लेता है लेकिन Git storage के साथ interoperates करता है। - Microsoft ने बहुत निवेश करके Git को बड़े repos और partial clones के लिए scale कराया।
Git बनाम Mercurial: UX और philosophy
- कई लोग hg की साफ़ CLI, consistent terminology, अच्छे Windows GUIs (जैसे TortoiseHg), और revsets तथा phases जैसी सुविधाओं की प्रशंसा करते हैं।
- कई लोग Git के confusing commands, dangerous flags, और idiosyncratic concepts (index/staging area, stash,
reset --hard) की भी आलोचना करते हैं। - प्रतिवाद: perceived difficulty का बड़ा हिस्सा distributed VCS concepts सीखने से आता है, न कि Git से खासतौर पर; समझ आने के बाद Git शक्तिशाली है और उसमें असल में data खोना मुश्किल है (reflog, आदि)।
- ऐतिहासिक divergence: Git ने शुरू से history rewriting को अपनाया; Mercurial दार्शनिक रूप से इसके प्रति सतर्क था, जिससे MQ और बाद में अधिक जटिल models (phases, evolve) जैसी चीज़ें आईं।
Code review workflows और GitHub UI
- गंभीर stacked workflows के लिए GitHub PR review की कड़ी आलोचना होती है: multiple versions को ठीक से नहीं संभालना, rebases के बाद context खो जाना, कमजोर range-diff support, unchanged lines पर सीमित commenting, और multi-round reviews में awkwardness।
- Gerrit और Phabricator जैसे systems को per-commit/stacked diffs और patch versions के बीच स्पष्ट evolution के लिए सराहा जाता है।
- Third-party tools (Graphite, CodeApprove, Reviewable) GitHub के ऊपर बेहतर review और stacked-diff workflows लाने की कोशिश करते हैं।
बड़े repos, monorepos, और binaries
- Git की monorepo कहानी को ऐतिहासिक रूप से कमजोर माना जाता है (submodules, sparse checkout, partial clone देर से आए)। कुछ लोग कहते हैं कि भारी tooling के बिना Git Google-style monorepos के लिए अच्छा fit नहीं है।
- दूसरे लोग मानते हैं कि Google scale से नीचे बड़े repos के लिए Git ठीक है और monorepos ज़्यादातर process/organization की समस्याएँ उजागर करते हैं।
- कहा जाता है कि game और ASIC development बड़े binaries के लिए Perforce पर निर्भर करते हैं; Git LFS व्यापक रूप से supported है, लेकिन Mercurial की largefile handling की तुलना में clunky और workflow-heavy कहा जाता है।
विकल्प और भविष्य की दिशाएँ
- कई लोगों को Fossil का all-in-one approach पसंद है (VCS + issue tracker + web UI) और single-binary deployment।
- Pijul को एक advanced patch-based VCS के रूप में उल्लेख किया गया है, जिसके अधिक आम होने की कुछ लोग आशा करते हैं।
- Jujutsu को एक promising Git-compatible VCS के रूप में highlight किया गया है, जिसमें operation log और built-in undo है, और जो Git तथा Mercurial दोनों से आगे VCS UX को modernize करने का लक्ष्य रखता है।
Mozilla का Git/GitHub की ओर कदम
- कई लोग Mozilla के Git पर switch को ecosystem realities और internal Git tooling पर निर्भरता (जैसे git-cinnabar एक bridge के रूप में) को देखते हुए व्यावहारिक मानते हैं।
- कुछ लोगों का तर्क है कि GitHub को खास तौर पर चुनना Mozilla के decentralization पर दिए गए कथित मूल्यों से टकराता है और contribution को Microsoft-controlled account पर निर्भर बना देता है।