jj v0.42.0 ออกแล้ว - ระบบควบคุมเวอร์ชันที่เข้ากันได้กับ Git

 (github.com/jj-vcs)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เปลี่ยนไปใช้ตัวจัดสรรหน่วยความจำ mimalloc เพื่อปรับปรุงประสิทธิภาพแบบมัลติเธรด
  • ลบ ตัวเลือกคำสั่งที่เตรียมเลิกใช้ เช่น jj commit --reset-author/--author, jj describe --no-edit/--edit/--reset-author/--author
  • ลบตัวเลือก jj git push --allow-new, jj metaedit --update-committer-timestamp
  • ลบ ตัวเลือกการตั้งค่าที่เตรียมเลิกใช้ เช่น git.auto-local-bookmark, git.push-new-bookmarks
  • jj evolog ยุติการรองรับ predecessor ของคอมมิตแบบเลกาซีที่บันทึกก่อน jj 0.30
  • การเติมคำสั่งอัตโนมัติของเชลล์จะแสดงคำอธิบายของ alias, revset-alias, template-alias และ fileset-alias ที่ผู้ใช้กำหนดเอง พร้อมดึงคำอธิบายจากฟิลด์ .doc ของการกำหนด alias แบบตาราง
  • jj show รับหลาย revision ได้ และแสดงแต่ละ revision ตามลำดับให้ใกล้เคียงกับ git show มากขึ้น
  • jj git fetch สร้าง evolution history โดยอิงจาก change ID และหากรีโมตรักษา change ID ไว้ ก็จะ rebase revision ลูกหลานในเครื่องขึ้นไปบน parent ที่ถูกเขียนใหม่
  • คำสั่ง jj util backend name จะแสดงชื่อคอมมิตแบ็กเอนด์ที่ใช้อยู่ในรีโพซิทอรีปัจจุบัน
  • เพิ่มการตั้งค่า edit-invocation-mode สำหรับ diff editor โดยเมื่อกำหนด "file-by-file" จะเรียกตัวแก้ไขหนึ่งครั้งต่อไฟล์ที่เปลี่ยน ทำให้ใช้เครื่องมือแบบรายไฟล์อย่าง vimdiff ได้
  • jj git remote add จะรายงานข้อผิดพลาดแทนการ panic เมื่อชื่อรีโมตว่างเปล่าหรือมีช่องว่าง
  • color-words diff เมื่อปิดการแสดงผลสี จะแสดง before/after แยกคนละบรรทัด ช่วยให้อ่าน diff ที่ถูก pipe หรือ redirect ได้ดีขึ้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Lobste.rs

  • ถ้า jj git fetch ตอนนี้สร้าง ประวัติวิวัฒนาการตาม change ID ได้ หมายความว่าถ้ารีโมตรักษา change ID เอาไว้ เราก็ไม่ต้องรัน jj new main ทุกครั้งหลัง jj git fetch แล้วใช่ไหม
    ถ้าเป็นแบบนั้นก็ดูเป็นการปรับปรุงคุณภาพชีวิตที่ดีพอสมควร

    • อ่านแล้วไม่รู้สึกว่าเป็นแบบนั้นนะ พอ fetch แล้วก็ยังมี change ที่ต่างจากเดิมโผล่มาบน main อยู่ดี เลยน่าจะไม่ช่วยในจุดนั้น
    • ถ้าเพิ่ม trailer ลงในข้อความ commit รีโมตไหน ๆ ก็จะเก็บมันไว้
      แต่ไม่แน่ใจว่าในกรณี merge commit ที่ GitHub สร้าง และไม่มี change ID จะเป็นอย่างไร

  • ส่วนที่บอกว่าเปลี่ยนไปใช้ตัวจัดสรรหน่วยความจำ mimalloc เพื่อเพิ่ม ประสิทธิภาพแบบมัลติเธรด นี่น่าสนใจกว่า
    สำหรับโปรเซสที่รันยาว ๆ ฉันเคยใช้พวก jemalloc เพื่อลด fragmentation แต่ jj ให้ความรู้สึกว่าเริ่มใน 1ms และจบภายใน 10ms เลยแปลกใจที่การเปลี่ยน allocator จะส่งผลให้รู้สึกได้
    ลองหาดูเพิ่มแล้ว เจอ PR คือ https://github.com/jj-vcs/jj/pull/9484 กับประมาณนี้ https://github.com/jj-vcs/jj/issues/2490#issuecomment-2595323515 แต่ก็ดูไม่ได้เร็วขึ้นมากนัก ถึงอย่างนั้นถ้าเร็วขึ้นและแก้แค่ไม่กี่บรรทัดก็ดีอยู่

  • ที่บอกว่า “ถ้ารีโมตรักษา change ID เอาไว้” นี่คือปกติแล้วรีโมตทั่วไปรักษามันไว้ด้วยเหรอ
    รู้ว่า jj gerrit upload จะเพิ่ม change ID footer แต่ jj git push ปกติไม่ได้ทำแบบนั้น

    • ถ้า commit ไม่ถูกเขียนใหม่ ก็ถือว่าน่าจะถูกรักษาไว้
      แต่การกระทำที่เขียน commit ใหม่อย่าง squash merge หรือ rebase merge ของ GitHub จะไม่เก็บไว้ ถ้าประมวลผลด้วยเครื่องมือมาตรฐานที่อิง libgit2 ก็จะไม่เก็บ custom header ส่วนเครื่องมือบางตัวอย่างไลบรารี Rust ที่ GitButler ใช้รองรับการเก็บ custom header แต่ก็ไม่แน่ใจว่า forge ต่าง ๆ จะใช้ของแบบนั้นหรือเปล่า
    • อยากรู้ว่ารีโมตไหนบ้างที่รักษา change ID เอาไว้
      และก็ไม่รู้ด้วยว่าจะตรวจสอบอย่างไรว่าเก็บไว้อย่างถูกต้องหรือไม่
    • change ID ที่พูดถึงตรงนี้น่าจะหมายถึง jujutsu change ID ไม่ใช่ Gerrit change ID
      มีข้อมูลเพิ่มเติมในเอกสาร
    • GitLab เก็บไว้ ตอนนี้ที่บริษัทก็ใช้งานกันแบบนั้น
      GitHub ก็เก็บไว้เหมือนกัน ดูได้จากคอมมิตของ pushcx ในโค้ดเบสของ lobsters หรือคอมมิตของฉัน

  • อยากรู้ว่ามีอะไรให้อ่านหรือดูบ้างเกี่ยวกับ เหตุผลที่ควรใช้ jj แทน Git มาตรฐาน
    รู้ว่า jj ทำงานบน Git ได้ และก็เคยลองกับโปรเจกต์เล่น ๆ มาแล้ว แต่ยังหาจุดดึงดูดแบบชี้ขาดไม่ได้ว่าทำไมมันถึงดีกว่าหรือง่ายกว่า