jj init – Jujutsu के साथ Git को बदलने को लेकर गंभीर होता हुआ

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

Jujutsu (“jj”) नाम का एक नया version-control tool Git के user-facing workflow को बदलने का लक्ष्य रखता है, जबकि मौजूदा Git repositories के साथ compatible बना रहता है। टिप्पणीकार jj के उस मॉडल को लेकर उत्सुक हैं जिसमें working copy हमेशा एक commit होती है, history editing और stacked changes को संभालने का उसका सरल तरीका, और बड़े या जटिल workflows में संभावित फायदे—लेकिन कई लोग Git के index को खोने, अवधारणात्मक जटिलता बढ़ने, और इस पर सवाल उठाने को लेकर संदेह में हैं कि क्या developers को इसके बजाय सिर्फ Git के underlying model को सीखना चाहिए। कुल मिलाकर, लोग ergonomics और tooling सुधारने के लिए jj में संभावना देखते हैं, लेकिन शक करते हैं कि यह Git की dominance को मात दे पाएगा या Git की underlying complexity से पूरी तरह बच पाएगा।

Jujutsu (jj) की समग्र प्रतिक्रिया

  • कई टिप्पणीकार jj को लेकर उत्सुक हैं और उसे आज़माने की योजना बना रहे हैं, खासकर वे जो पहले से ही Git के UI से निराश हैं।
  • कुछ लोग जिन्होंने स्विच किया है, शुरुआती झिझक की बात करते हैं, मुख्यतः “working copy is a commit” मॉडल की वजह से, लेकिन कहते हैं कि एक बार जब यह “समझ में” आ जाता है, तब Git खुरदुरा लगता है।
  • अन्य लोग संदेह में हैं और jj को version control को सच में सरल बनाने के बजाय Git के ऊपर जटिलता जोड़ने वाला मानते हैं।

Working copy as a commit और index का अभाव

  • jj का मॉडल: सभी बदलाव हमेशा एक commit का हिस्सा होते हैं; कोई exposed “index” या unstaged state नहीं होता।
  • समर्थकों का तर्क है कि इससे वैचारिक अवस्थाएँ कम होती हैं और commit को split करने जैसी operations आसान तथा कम error-prone हो जाती हैं।
  • आलोचकों को Git का दो-चरणीय “add then commit” पसंद है, क्योंकि उनके अनुसार यह जानबूझकर संबंधित बदलावों को समूहित करने को प्रोत्साहित करता है और सब कुछ auto-commit होने से बचाता है।
  • इस बात को लेकर कुछ भ्रम है कि क्या jj index-जैसा व्यवहार वास्तव में संरक्षित रखता है; एक टिप्पणीकार स्पष्ट करता है कि यह प्रभावी रूप से डिफ़ॉल्ट रूप से सभी बदलाव commit कर देता है।

Commit splitting और workflows

  • jj के split command पर बहुत चर्चा होती है।
  • प्रशंसक कहते हैं कि यह commits को retroactively split करने और history को पुनर्गठित करने में Git के multi-step rebases की तुलना में friction बहुत कम कर देता है।
  • विरोधियों को jj split का workflow सहज नहीं लगता (जैसे कौन-सा हिस्सा “first” माना जाता है vs “second”), और उनका तर्क है कि splitting इतनी महत्वपूर्ण चीज़ है कि उसे “weird” नहीं होना चाहिए।

Git की जटिलता, mental models, और सीखने का बोझ

  • कई टिप्पणियाँ Git के उलझाऊ concepts पर अफ़सोस जताती हैं (detached HEAD, reflog, rebase merge semantics, ours/theirs inversion), और “footguns” की बारंबारता पर भी।
  • अन्य लोग Git का बचाव करते हैं कि यह शक्तिशाली है लेकिन अगर आप इसके core model को आत्मसात कर लें तो अत्यधिक कठिन नहीं है; उनका तर्क है कि developers को tools को अधिक गहराई से सीखना चाहिए, और वे इसकी तुलना databases या networking को समझने से करते हैं।
  • इस पर असहमति है कि “internals को समझने की ज़रूरत” रोज़मर्रा के उपयोग के लिए उचित है या नहीं।

Tooling, GUIs, और बड़े repos

  • कई लोग अच्छे GUIs के महत्व पर ज़ोर देते हैं (staging, hunk selection, bisect, reflog के लिए) और कहते हैं कि अगली पीढ़ी का VCS GUI-first होना चाहिए।
  • कुछ लोग नोट करते हैं कि jj में फिलहाल mature GUI support नहीं है, जो उन workflows को कमजोर करता है जो index-जैसे staging अनुभव पर बहुत निर्भर हैं।
  • बड़े repos के लिए, watchman को jj की performance सुधारने के तरीके के रूप में उल्लेख किया गया है, लेकिन overall large-repo behavior पर कम चर्चा है और यह कुछ हद तक अस्पष्ट बना हुआ है।

Meta बिंदु: नामकरण, ecosystem, और longevity

  • binary नाम jj के सामान्य Vim keybindings से टकराने को लेकर चिंताएँ दिखाई देती हैं।
  • कुछ लोग Google-funded काम से जुड़ाव के कारण jj की longevity को लेकर चिंतित हैं, जबकि अन्य स्पष्ट करते हैं कि यह Git fork नहीं है और केवल libgit का उपयोग करता है।
  • कुछ लोग सुझाव देते हैं कि सबसे ज़रूरी चीज़ नया VCS नहीं, बल्कि एक अधिक समझदार Git-compatible interface या frontend है।