jj v0.42.0 रिलीज़ - Git संगत वर्ज़न मैनेजमेंट सिस्टम

 (github.com/jj-vcs)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • mimalloc मेमोरी allocator पर स्विच करके मल्टीथ्रेड performance में सुधार
  • jj commit --reset-author/--author, jj describe --no-edit/--edit/--reset-author/--author आदि deprecated command options हटाए गए
  • jj git push --allow-new, jj metaedit --update-committer-timestamp options हटाए गए
  • git.auto-local-bookmark, git.push-new-bookmarks आदि deprecated config options हटाए गए
  • jj evolog ने jj 0.30 से पहले रिकॉर्ड किए गए legacy commit predecessor के support को बंद किया
  • shell autocompletion अब user-defined alias, revset-alias, template-alias, fileset-alias के description दिखाती है, और table-form alias definitions के .doc field से description निकालती है
  • jj show अब कई revisions लेकर git show के अधिक करीब हर revision को क्रम से दिखाता है
  • jj git fetch change ID-आधारित evolution history बनाता है, और अगर remote change ID को preserve करता है तो local descendant revisions को rewritten parent के ऊपर फिर से rebase करता है
  • jj util backend name कमांड मौजूदा repository में इस्तेमाल हो रहे commit backend का नाम दिखाता है
  • diff editor के लिए edit-invocation-mode setting जोड़ी गई; "file-by-file" सेट करने पर हर बदली हुई file के लिए editor एक-एक बार चलता है, जिससे vimdiff जैसे file-level tools का उपयोग संभव होता है
  • jj git remote add अब खाली remote name या spaces वाले remote name पर panic की जगह error report करता है
  • color output बंद होने पर color-words diff अब before/after को अलग पंक्तियों में दिखाता है, जिससे piped या redirected diff की readability बेहतर होती है

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Lobste.rs की राय

  • अगर jj git fetch अब change ID-आधारित evolution history बनाता है, तो क्या इसका मतलब है कि यदि remote change ID को सुरक्षित रखता है, तो हर बार jj git fetch के तुरंत बाद jj new main करने की ज़रूरत नहीं रहेगी?
    अगर ऐसा है, तो यह काफ़ी अच्छा quality-of-life improvement लगता है

    • मुझे ऐसा पढ़ने पर नहीं लगता। fetch करने पर पहले से अलग change main पर आ जाएगा, इसलिए उस हिस्से में शायद इससे मदद नहीं मिलेगी
    • commit message में trailer जोड़ दें तो कोई भी remote उसे सुरक्षित रखेगा
      बस यह नहीं पता कि GitHub-generated merge commit में, जहाँ change ID नहीं होता, तब क्या होगा

  • mimalloc memory allocator पर स्विच करके multi-threaded performance बढ़ाने वाली बात ने ज़्यादा उत्सुक किया
    लंबे समय तक चलने वाली processes में fragmentation कम करने के लिए मैंने jemalloc जैसी चीज़ें इस्तेमाल की हैं, लेकिन jj तो ऐसा लगता है जैसे 1ms में शुरू होकर 10ms के भीतर खत्म हो जाता है, इसलिए allocator बदलने का असर महसूस होना थोड़ा surprising है
    थोड़ा और खोजने पर PR https://github.com/jj-vcs/jj/pull/9484 मिला, और https://github.com/jj-vcs/jj/issues/2490#issuecomment-2595323515 के अलावा ज़्यादा कुछ नहीं मिला, पर यह कोई बहुत बड़ा speedup नहीं लगता। फिर भी अगर यह तेज़ है और बदलाव भी बस कुछ लाइनों का है, तो ठीक है

  • इसमें कहा गया था, “अगर remote change ID को सुरक्षित रखता है”, लेकिन मुझे नहीं पता आम तौर पर remote ऐसा करते भी हैं या नहीं
    मुझे पता है कि jj gerrit upload change ID footer जोड़ता है, लेकिन सामान्य jj git push ऐसा नहीं करता

    • जब तक commit दोबारा rewrite न किया जाए, तब तक इसे सुरक्षित माना जा सकता है
      लेकिन GitHub के squash merge या rebase merge जैसी operations, जो commit को फिर से लिखती हैं, उसे सुरक्षित नहीं रखेंगी। standard libgit2-based tools से प्रोसेस करने पर custom header सुरक्षित नहीं रहता, जबकि GitButler द्वारा इस्तेमाल की जाने वाली Rust library जैसी कुछ tools custom header preservation सपोर्ट करती हैं, लेकिन forge वास्तव में ऐसी चीज़ें इस्तेमाल करते हैं या नहीं, इस पर संदेह है
    • जानना चाहूँगा कि कौन-कौन से remote change ID को सुरक्षित रखते हैं
      और यह भी नहीं पता कि यह सही तरह से सुरक्षित हो रहा है या नहीं, इसे जाँचना कैसे चाहिए
    • यहाँ जिस change ID की बात हो रही है, वह Gerrit change ID नहीं बल्कि jujutsu change ID लगता है
      docs में इस पर और जानकारी है
    • GitLab इसे सुरक्षित रखता है। हमारी कंपनी में अभी ऐसे ही इस्तेमाल हो रहा है
      GitHub भी सुरक्षित रखता है; lobsters codebase में pushcx के commit या मेरे commits देखकर यह जाँचा जा सकता है

  • मैं यह पढ़ने या देखने लायक सामग्री ढूँढ रहा हूँ कि standard Git की जगह jj क्यों इस्तेमाल करें
    मुझे पता है कि jj Git के ऊपर काम कर सकता है, और मैंने hobby projects में इसे आज़माया भी है, लेकिन यह क्यों बेहतर या आसान है, इस बारे में अभी तक कोई निर्णायक आकर्षण नहीं मिला