मुझे jj में भविष्य दिखता है

 (steveklabnik.com)
12 पॉइंट द्वारा GN⁺ 2025-10-24 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • नया version control system jj Rust में लिखा गया एक प्रोजेक्ट है, जो मौजूदा Git की सीमाओं को पूरा करता है और क्रमिक रूप से अपनाए जाने योग्य संरचना वाला एक टूल है
  • लेखक का मानना है कि, Rust की विकास क्षमता का पहले विश्लेषण करने के अपने अनुभव के आधार पर, jj में भी market fit, विशेषज्ञ टीम, और user base के लिहाज़ से वैसी ही संभावनाएँ हैं
  • jj Git repositories के साथ compatible रहते हुए भी अधिक सरल workflow देता है, इसलिए खासकर उन developers के लिए इसकी पहुँच अधिक है जो Git की आंतरिक संरचना से परिचित नहीं हैं
  • Google और Oxide जैसी जगहों पर इसका वास्तविक उपयोग बढ़ रहा है, और उत्साही community तथा समर्पित development team बन चुकी है
  • लेखक ERSC में शामिल हो रहे हैं, जो jj-आधारित collaboration platform बना रही है, और Rust के शुरुआती दौर की तरह jj ecosystem की वृद्धि को सीधे आगे बढ़ाने की योजना रखते हैं

Rust को चुनने की वजह

  • लेखक ने 2012 के Christmas पर Hacker News में “Rust 0.5 released” की खबर देखी और इस भाषा में रुचि ली
    • उस समय वे Ruby on Rails developer थे, लेकिन कॉलेज के दिनों से ही compiler और systems programming में रुचि रखते थे
  • Rust की सफलता की संभावना का आकलन करते समय उन्होंने तीन तत्व देखे: market fit, development team, user base
    • C/C++ की जगह लेने लायक कोई भरोसेमंद भाषा नहीं थी, और Rust ने garbage collection के बिना memory safety देने वाला एक अभिनव तरीका पेश किया
    • Mozilla इसका समर्थन कर रहा था और Firefox में Rust लाने की योजना थी, इसलिए लेखक ने माना कि वास्तविक उपयोग का आधार बनने की संभावना अधिक है
  • Rust community का मित्रवत और सहयोगी माहौल भी एक आकर्षक कारण था
    • बाद में लेखक ने “Rust for Rubyists” tutorial लिखा और आधिकारिक documentation के सह-लेखक बने

jj का आगमन

  • jj(Jujutsu) कोई programming language नहीं, बल्कि एक नया version control system(VCS) है, जिसे Rust में बनाया गया है
    • यह Git के साथ compatible है और मौजूदा repositories को वैसे ही इस्तेमाल करते हुए इसे क्रमिक रूप से अपनाया जा सकता है
  • लेखक ने तकनीकी रुचि में अपने जैसे developer Rain की सिफारिश के बाद jj को देखना शुरू किया
    • Rain Meta की source management team से रही हैं, इसलिए उनकी सिफारिश को एक भरोसेमंद संकेत माना गया
  • लेखक ने सप्ताहांत में खुद jj पर प्रयोग करते हुए tutorial लिखने का प्रोजेक्ट शुरू किया
    • Rust सीखने के समय की तरह उन्होंने लिखते हुए concepts को व्यवस्थित करने का तरीका अपनाया
    • नतीजतन tutorial को community से सकारात्मक प्रतिक्रिया मिली

jj का भविष्य

  • लेखक को jj में Rust के शुरुआती दौर जैसा growth pattern दिखता है
    • market fit, team capability, और user adoption की संभावना — सभी सकारात्मक हैं
  • market fit के लिहाज़ से Git की स्थिति बेहद मजबूत है, लेकिन jj Git repositories को सीधे संभाल सकता है, इसलिए इसका आंशिक adoption संभव है
    • Oxide के भीतर भी Rain से शुरू होकर इसका उपयोग फैल रहा है, और इसके लिए dedicated channel तक बन गया है
  • Google के भीतर भी jj का उपयोग हो रहा है, जिसे Mozilla द्वारा Rust अपनाने जैसे संकेत के रूप में देखा जा रहा है
    • Google के बड़े monorepo (Piper backend आधारित) में भी कुछ projects jj का उपयोग कर रहे हैं, और यह social proof की तरह काम करता है
  • सीखने की एक curve मौजूद है, लेकिन जो लोग Git की आंतरिक संरचना से परिचित नहीं हैं, उनके लिए यह उलटे ज़्यादा सहज और सरल usability देता है
    • Git experts को नए concepts के साथ सामंजस्य बैठाना पड़ सकता है, लेकिन सामान्य developers जल्दी अभ्यस्त हो जाते हैं
  • jj community उत्साही और दोस्ताना माहौल के साथ बढ़ रही है, जो शुरुआती Rust community की याद दिलाती है

jj टीम और community

  • संस्थापक Martin लंबे समय से jj के विकास के लिए समर्पित रहे हैं, और हाल में उन्होंने इसे व्यक्तिगत account से आधिकारिक organization account में स्थानांतरित कर governance को व्यवस्थित किया है
  • टीम के सदस्य source control tools बनाने का गहरा अनुभव रखने वाले विशेषज्ञ हैं, और तकनीकी दिशा व quality control में मजबूत हैं
  • community सक्रिय feedback और सहयोग के माध्यम से तेजी से बढ़ रही है, और शुरुआती Rust community की सकारात्मक ऊर्जा को फिर से दिखा रही है

नई चुनौती: ERSC में शामिल होना

  • लेखक ने Oxide छोड़कर jj-आधारित collaboration platform बनाने वाले startup ERSC में शामिल होने का फैसला किया है
    • Oxide एक शानदार workplace था, लेकिन jj ecosystem में और गहराई से शामिल होने की इच्छा निर्णायक कारण बनी
  • ERSC jj के ऊपर developer collaboration platform बनाने जा रही है, और GitHub के Logical Awesome नामक corporate entity के रूप में शुरू होने के उदाहरण से इसी तरह के शुरुआती चरण को समझाया गया है
  • लेखक Oxide में अपना काम पूरा करने के बाद कुछ समय विश्राम करेंगे, और फिर jj community activities तथा tutorial को पूरा करने पर ध्यान देंगे
    • Discord पर अधिक सक्रियता, blog series, और community contributions की भी बात की गई है
  • वे 2025 को एक नए turning point के रूप में देखते हैं और इस बात के लिए आभार जताते हैं कि उन्हें उस project पर काम करने का मौका मिल रहा है जिसके प्रति वे सचमुच उत्साही हैं

निष्कर्ष

  • लेखक को भरोसा है कि jj में Rust की growth trajectory को दोहराने की क्षमता है
    • Git compatibility, क्रमिक adoption की संभावना, समर्पित टीम, और सक्रिय community इसके आधार हैं
  • jj सिर्फ एक टूल से बढ़कर, developer collaboration के तरीके को बदलने वाला platform बन सकता है
  • Rust से शुरू हुई लेखक की यात्रा अब jj के साथ एक नए अध्याय में आगे बढ़ रही है

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

2 टिप्पणियां

 
tujuc 2025-10-24

यह कई बार सामने आ चुका है, अब एक बार देखना चाहिए।
 
GN⁺ 2025-10-24
Hacker News राय

  • मैंने jj को लगभग दो बार गंभीरता से इस्तेमाल करके देखा है। first-class conflict का कॉन्सेप्ट शानदार है, लेकिन व्यवहार में टकराव सुलझाने से कहीं ज़्यादा बार staging/commit करना पड़ता है। magit से आने की वजह से jj का hunk split और selection फीचर मुझे बहुत असुविधाजनक लगा। मैं rebase काफ़ी करता हूँ, इसलिए magit के rebase shortcuts से मैं पहले ही jj के ज़्यादातर फ़ायदे ले रहा था। मेरे जैसे लोगों के लिए jj को magit से बेहतर बनना है तो hunk selection UX में काफ़ी सुधार करना होगा

    • jj में staging या commit के बारे में न सोचना ही मुख्य बात है। सब कुछ एक change है, और आपको parent या उससे पुराने ancestor को bookmark करके उसमें squash करना है या bookmark को अगले change पर ले जाना है—सोचने का तरीका यही होना चाहिए
    • मैं भी rebase बहुत करता हूँ, लेकिन jj की यह बहुत ज़्यादा opinionated version control philosophy मुझे पसंद नहीं है। खासकर नए लोगों के लिए इसकी internal design को इतना छिपाना सीखने में मददगार नहीं लगता
    • magit का hunk selection UX ठीक-ठीक कैसा है, यह जानने में दिलचस्पी है। मुझे यह jj से बहुत अलग नहीं लगा। मैंने लंबे समय तक GitUp(gitup.co) इस्तेमाल किया है, और jj का UX पूरी तरह नैचुरल नहीं है, लेकिन यह shortcut customization से सुलझने वाली समस्या लगती है
    • अगर आप समझते हैं कि Git के ऊपर अच्छा UX देना क्यों ज़रूरी है, तो आप jj की philosophy का 95% पहले ही समझ चुके हैं
    • jj में git index भी इस्तेमाल किया जा सकता है। बस git_head बदलने वाले jj commands का उपयोग नहीं करना चाहिए। मैं staged changes से commit करने के लिए एक alias बनाकर इस्तेमाल करता हूँ (config.toml उदाहरण)

  • Git के विकल्प दिखते ही मुझे थोड़ा लुडाइट जैसा एहसास होता है। भाषाएँ, frameworks और tools पहले ही बहुत ज़्यादा हैं। कम-से-कम VCS के मामले में Git जैसा लगभग सार्वभौमिक समाधान होना राहत की बात है। jj कुछ समस्याएँ हल कर सकता है, लेकिन पूरे उद्योग को दो systems सपोर्ट करने का बोझ उठाना पड़े, तो शायद उसका शुद्ध लाभ नहीं निकलेगा

    • Git की खराब UI इतनी परेशान करती है कि मैं चाहता हूँ इसे बदला जाए। कोई नया tool आए जो Git के concepts को बेहतर तरीके से समझाए
    • jj एक ऐसा विकल्प है जिसे individual developer चुन सकता है। jj repo, git repo का superset है, इसलिए मौजूदा tools टूटते नहीं हैं
    • मैंने पहले एक ऐसी कंपनी में काम किया था जो svn इस्तेमाल करती थी, और वहाँ git-svn के ज़रिए पहले Git इस्तेमाल किया था। jj भी कुछ वैसा ही रास्ता अपनाता दिखता है। jj को जाने बिना भी मौजूदा CI या tools वैसे ही काम करते हैं
    • Git productivity कम करने वाला कारक है, और agent-based coding के दौर में यह और बड़ी समस्या है। मेरे हिसाब से jj काफ़ी revolutionary नहीं है। इसके बजाय ऐसा नया VCS चाहिए जो बदलावों को atomic स्तर पर track करे। ऐसी संरचना में branch का कॉन्सेप्ट गायब हो सकता है, और repo state को plan और atom से बनाया जा सकता है। हालांकि ऐसे system पर जाना बहुत बड़ी चुनौती होगी
    • जैसे rcs, cvs, svn के बाद git आया, वैसे ही git भी किसी दिन किसी बेहतर चीज़ से बदला जाएगा

  • मैंने jj इस्तेमाल किया है, लेकिन मैं Sublime Merge का आदी हूँ। CLI से version control करने पर बार-बार टाइप करना पड़ता है और state खोना आसान होता है। GUI में state हमेशा दिखती रहती है और एक क्लिक में diff या commit message input किया जा सकता है। keyboard से hunk चुनना मैं फिर कभी नहीं करना चाहूँगा। SM वाकई बहुत आरामदायक है। अच्छा होगा अगर jj GUI बेहतर हो जाए या SM में jj integrate हो जाए

  • असली खबर यह है कि लोग “jjhub” जैसी चीज़ें बनाना शुरू कर चुके हैं (ersc.io)

    • मुझे लगता है ‘jjhub’ एक ठीक-ठाक पहला कदम है। पहले से ही jj को github के साथ इस्तेमाल किया जा सकता है, लेकिन इससे आगे बढ़कर वास्तव में मूल्यवान कुछ देना होगा
    • जानकारी के लिए, यह भी है: Stacking ब्लॉग पोस्ट
    • Gerrit भी jj के concepts के साथ अच्छी तरह मेल खाता है, और Jujutsu change ID support जोड़ने वाला RFC मंज़ूर हो चुका है
    • jjhub नाम काफ़ी बढ़िया है
    • मैं सच में चाहता हूँ कि यह सफल हो। Github के असली विकल्प का समय आ गया है

  • कहा जा रहा है कि Google के अंदर jj फैल रहा है, लेकिन Google में समय-समय पर internal VCS बदलने की प्रवृत्ति रही है। git wrapper, mercurial का extended version, और अब jj—7 साल के भीतर सब बदल गया

    • सच कहें तो Google के ज़्यादातर internal tools की उम्र छोटी होती है। फिर भी jj इस मायने में innovative है कि यह change की identity बनाए रखता है। git में rebase या amend के बाद commit पूरी तरह अलग हो जाता है, लेकिन jj उसे उसी change के रूप में track करता है। हालांकि jj अंततः git को storage backend के रूप में इस्तेमाल करता रहेगा, इसकी संभावना ज़्यादा है
    • उम्मीद है jj बना रहेगा। मैं दफ़्तर और घर दोनों जगह एक ही workflow इस्तेमाल करना चाहता हूँ। यह mercurial से काफ़ी तेज़ है
    • लगता है इस बार इरादा Perforce fork को भी साथ में हटाने का है। बाहर से देखने पर बदलाव कुछ ज़्यादा ही लगते हैं
    • git wrapper मूल रूप से experimental था, और mercurial-आधारित system लगभग 10 साल तक चला

  • मुझे जानना है कि क्या jj बड़े binary files को git से बेहतर संभालता है। game development में अब भी Perforce का दबदबा है। git में LFS होने पर भी वह काफ़ी नहीं पड़ता

    • Perforce का binary support व्यवहार में Git LFS जैसा ही है। फ़र्क बस enterprise support जैसी चीज़ों का है
    • jj git को storage के तौर पर इस्तेमाल करता है और LFS support नहीं करता, इसलिए इस मामले में इसकी सीमाएँ git जैसी ही हैं
    • अभी के लिए कोई खास सुधार नहीं है, लेकिन इस क्षेत्र के बारे में जानकारी है और आगे बदलाव हो सकते हैं

  • मैंने लगभग एक दिन Jujutsu tutorial फॉलो किया और यह काफ़ी अच्छा लगा। लेकिन ऐसा लगा जैसे कोई गायब puzzle piece है। उदाहरण के लिए, GitHub पर PR भेजते समय change id वाकई कितना मददगार है, यह जानना चाहता था। शायद इसकी असली ताकत सिर्फ Google के अंदर Piper backend के साथ दिखती है। ERSC की योजना क्या है, यह जानने में दिलचस्पी है। व्यक्तिगत रूप से मैं built-in offline code review वाला distributed workflow चाहता हूँ

    • यह सुनकर खुशी हुई कि आपको इस्तेमाल करने में मज़ा आया :) अभी GitHub पर change id का लगभग कोई फायदा नहीं है। लेकिन jj-spr जैसे tools से कुछ अनुभव मिल सकता है। GitHub के SVP ने jj में दिलचस्पी दिखाई थी, ऐसा एक tweet भी था। और मैंने beads नाम का issues को repo के अंदर रखने वाला system इस्तेमाल किया है, जो मुझे काफ़ी पसंद आया
    • jj से बने commits में change-id header शामिल होता है, इसलिए GitHub को jj की जानकारी न हो तब भी jj users आपस में rebase tracking कर सकते हैं। इसे git cat-file -p HEAD से देखा जा सकता है

  • मैंने अपने personal projects में jj को 1–2 महीने इस्तेमाल किया है और अनुभव काफ़ी अच्छा रहा। लेकिन जब पुराने revisions को modify करते हैं, तो .gitignore में नए जोड़े गए files गलती से शामिल हो सकते हैं। इसके अलावा सब ठीक है। फिर भी अभी Git का ज्ञान कहीं ज़्यादा है, इसलिए इसे धीरे-धीरे कंपनी में लाने की सोच रहा हूँ

  • मैं इस साल Sapling/Subversion कंपनी में शामिल हुआ हूँ, लेकिन अभी jj इस्तेमाल नहीं कर पाया। फिर भी Sapling ज़्यादा intuitive लगता है, और commit stack को branch की तुलना में समझना आसान है। बस यह सोचता हूँ कि Meta के review UI जैसी support के बिना यह कितना आगे जा पाएगा। ऐसे projects की सच में ज़रूरत है

    • सही कहा, Sapling और jj एक ही दिशा में चलने वाले साथी प्रोजेक्ट्स हैं

  • नाम कुछ भी हो, East River Source Control वाकई बहुत शानदार नाम है