Jujutsu - ระบบจัดการเวอร์ชันแบบกระจายที่เข้ากันได้กับ Git ซึ่งเรียบง่ายและทรงพลัง

 (github.com/martinvonz)
4 คะแนน โดย GN⁺ 2023-08-02 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Jujutsu เป็น ระบบจัดการเวอร์ชัน ที่ใช้สำหรับคัดลอกโค้ด ติดตามการเปลี่ยนแปลง และเผยแพร่การเปลี่ยนแปลงของโปรเจ็กต์ซอฟต์แวร์ โดยออกแบบให้ใช้งานง่ายโดยคำนึงถึงทั้งผู้ใช้ใหม่และผู้มีประสบการณ์ รวมถึงทั้งโปรเจ็กต์ใหม่ส่วนบุคคลและประวัติ/ทีมขนาดใหญ่
  • มีการแยกส่วนติดต่อผู้ใช้และอัลกอริทึมการจัดการเวอร์ชันออกจาก ระบบจัดเก็บข้อมูล ที่ใช้เก็บเนื้อหาภายใน และปัจจุบันใช้ Git repository เป็นชั้นจัดเก็บข้อมูล จึงเข้ากันได้กับเครื่องมือที่อิงกับ Git
  • ใน Git จะเก็บเฉพาะ commit และไฟล์เท่านั้น ส่วน bookmark(branch) และเมทาดาทาระดับสูงอื่น ๆ จะถูกเก็บไว้ในที่เก็บข้อมูลแบบกำหนดเองภายนอก Git
  • Git backend เริ่มต้นใช้ไลบรารี Rust gitoxide และสามารถดึง branch จาก Git remote repository กับ push ไปยัง remote ได้ รวมทั้งสร้าง commit ที่ดูเหมือน Git commit ปกติ
  • ใช้โมเดล working-copy-as-a-commit ซึ่งแสดง working copy เป็น commit จริง โดยการเปลี่ยนแปลงไฟล์จะถูกบันทึกอัตโนมัติเป็น commit ปกติ และจะถูก amend ทุกครั้งที่มีการเปลี่ยนแปลงถัดไป
    • คำสั่งจะไม่ล้มเหลวเพราะ dirty working copy
    • ไม่จำเป็นต้องใช้ git stash
    • สามารถตั้ง commit message ให้กับ working copy commit ได้แม้งานจะยังไม่เสร็จ
  • ทุกการทำงานใน repository จะถูกบันทึกพร้อม snapshot ของสถานะ repository หลังการทำงาน ทำให้สามารถกู้คืนสถานะ repository ก่อนหน้า, undo เป็นรายงาน, และ revert งานใดงานหนึ่งที่ไม่ใช่งานล่าสุดได้
  • มีการบันทึก conflict เป็น อ็อบเจ็กต์ชั้นหนึ่ง เช่นเดียวกับ commit ดังนั้นแม้งานที่ทำให้เกิด conflict ก็ยังสำเร็จได้ และสามารถจัดการภายหลังด้วยเวิร์กโฟลว์การแก้ conflict แบบเดียว
  • เมื่อแก้ไข commit ระบบจะ rebase descendant ทั้งหมดของ commit เดิมขึ้นไปบน commit ใหม่โดยอัตโนมัติ ผลการแก้ conflict ก็จะถูกส่งต่อไปยัง descendant และ bookmark กับ working copy ที่ชี้ไปยัง rebased commit ก็จะถูกอัปเดตด้วย
  • ไม่มี index หรือ staging area แบบชัดเจน การเลือก commit ใช้ภาษา revset และรูปแบบผลลัพธ์ประมวลผลด้วยภาษา template ที่ผู้ใช้ตั้งค่าได้
  • มีความสามารถด้านการเขียนประวัติใหม่ เช่น jj describe สำหรับแก้ไขข้อความของ commit ใดก็ได้, jj diffedit สำหรับแก้ไขการเปลี่ยนแปลงของ commit โดยไม่ต้อง checkout, jj split สำหรับแยก commit, และ jj squash -i --from X --into Y สำหรับย้ายการเปลี่ยนแปลงบางส่วนไปยังอีก commit หนึ่ง
  • ความสามารถในการทำสำเนาพร้อมกันอย่างปลอดภัยเป็นฟีเจอร์ทดลอง โดยออกแบบมาเพื่อไม่ให้ repository อยู่ในสภาพเสียหายเมื่อใช้ระบบไฟล์แบบกระจายหรือเครื่องมือสำรองข้อมูล เช่น Dropbox และ rsync และในกรณีเลวร้ายที่สุดมีเป้าหมายให้แสดง conflict ระหว่างสถานะ local กับ remote
  • jj เป็นระบบจัดการเวอร์ชันเชิงทดลอง แม้ความเข้ากันได้กับ Git จะมีเสถียรภาพ แต่ก็อาจยังมีฟีเจอร์ที่กำลังพัฒนา, UX ที่ยังไม่เหมาะที่สุด, และช่องว่างของเวิร์กโฟลว์สำหรับวิธีใช้งานบางแบบ
  • ฟีเจอร์ต่าง ๆ ค่อนข้างสมบูรณ์แล้ว แต่การรองรับ Git submodule ยังไม่เสร็จสิ้น ยังมี performance bug หลายจุด และยังไม่มีการรองรับเวิร์กโฟลว์แบบอิงอีเมลโดยตรง
  • ก่อนถึง 1.0.0 จะยังมีการเปลี่ยนแปลงเวิร์กโฟลว์และการเปลี่ยนแปลงรูปแบบข้อมูลบนดิสก์ที่ไม่เข้ากันย้อนหลัง และสำหรับการเปลี่ยนรูปแบบจะพยายามมีการอัปเกรดแบบโปร่งใส หรือจัดเตรียมคำสั่ง/สคริปต์อัปเกรดเมื่อมีการร้องขอ
  • เป็นซอฟต์แวร์โอเพนซอร์สภายใต้สัญญาอนุญาต Apache 2.0 ไม่ใช่ผลิตภัณฑ์ที่ Google ให้การสนับสนุน และการสนับสนุนมาจากชุมชน

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

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

 
xguru 2023-08-03

Jujutsu - ระบบจัดการเวอร์ชันแบบกระจายที่เข้ากันได้กับ Git ซึ่งเรียบง่ายและทรงพลัง

ผมเคยโพสต์เรื่องนี้ไว้เมื่อปีกว่าแล้ว แต่ตอนนี้มันกลับมาเป็นประเด็นบน HN อีกครั้งครับ
 
GN⁺ 2023-08-02
ความคิดเห็นจาก Hacker News

  • ดีใจที่เห็นเรื่องนี้ขึ้นมาในนี้ ผมเพิ่งย้ายมาใช้ jj เมื่อประมาณ 2–3 สัปดาห์ก่อน และไม่คิดจะกลับไปใช้แบบเดิมแล้ว แม้ต้องเปลี่ยนวิธีคิดเรื่องการทำงานในหัวไปพอสมควร แต่ก็ชอบ flow ที่ jj มอบให้มาก
    เวลาในการคิดแยกว่าจะ commit อะไรก็หายไป เพราะการเปลี่ยนแปลงไฟล์ทั้งหมดจะถูกสะท้อนเข้าไปใน working-copy commit โดยอัตโนมัติ แน่นอนว่าบางครั้งก็ไม่ต้องการแบบนั้น จึงมีฟีเจอร์สำหรับแยก commit ออกเป็นสองส่วนหรือย้ายการเปลี่ยนแปลง และชอบตรงที่ ทุกการทำงานทำกับ commit เป็นเป้าหมาย
    jj log ยอดเยี่ยมสำหรับดูแผนที่ทั้งหมดของหลาย branch, conflict สามารถแก้เพียงบางส่วนแล้วค่อยย้ายไป branch อื่นได้ และ changeset ID แบบย่อก็สะดวก เช่น ใน jj log เห็น changeset ที่จะ rebase แล้วสั่งได้ประมาณ jj rebase -s qr -d master ซึ่งเร็วกว่าเขียนชื่อ branch เต็ม ๆ

    • สงสัยว่าถ้าเผลอบันทึกไฟล์ที่มีค่าลับแล้วมันถูกดูดเข้าไปโดยอัตโนมัติจะเกิดอะไรขึ้น
    • สงสัยว่าใช้ร่วมกับ GitHub repository ธรรมดา ๆ ได้หรือไม่
      เห็นบอกว่าใช้กับ backend อย่าง Dropbox ได้ แต่ถ้ามีระบบที่ใช้กับ IPFS ได้ง่ายก็คงดี สำหรับข้อมูลขนาดใหญ่ เราเก็บ 1TB บน GitHub ไม่ได้ และมองข้าม LFS ไปเพราะเป็นบริการเสียเงิน
      คนที่ต้องใช้ dataset ก็ต้องมีไว้ในเครื่องอยู่แล้ว ดังนั้น IPFS ซึ่งทำให้แหล่งดาวน์โหลดไม่ได้มีแค่ที่เดียวแต่มีได้เป็นพัน ๆ แห่ง จึงเป็นทางออกที่เป็นธรรมชาติ ถ้าใช้ IPFS เป็น data store ได้ก็คงย้ายทันที แต่ถ้าไม่ใช่ ก็คิดว่าไม่ค่อยคุ้มที่จะลองดู
    • อยากรู้ว่ามีทีมไหนใช้สำเร็จจริงบ้างหรือไม่ อยากรู้ว่าถ้าสองคนทำงานบน branch เดียวกันจะเป็นความรู้สึกแบบไหน

  • Jujutsu เริ่มจากโปรเจกต์ส่วนตัวของผู้เขียน และตอนนี้กลายเป็นโปรเจกต์ประจำเต็มเวลาของผู้เขียนที่ Google เคยมีการนำเสนอในงาน Git Merge 2022
    Jujutsu: A Git-Compatible VCS - Git Merge 2022:
    Video:
    https://youtu.be/bx_LGilOuE4
    Slides:
    https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX...

    • การที่โปรเจกต์ส่วนตัวกลายเป็น โปรเจกต์เต็มเวลา ที่ Google ได้นี่คงน่าภูมิใจไม่น้อย

  • ใช้ jj เป็นประจำทุกวันมาเกือบ 1 ปีแล้ว และมองว่าดีกว่า UX ของ Git อย่างชัดเจน เป็นคนที่ค่อนข้างใส่ใจกับการแบ่งการเปลี่ยนแปลงออกเป็น atomic commit ดังนั้น automatic rebase จึงเป็นฟีเจอร์สำคัญมาก
    เพราะสามารถบันทึก conflict ไว้ใน commit ได้ จึงไม่จำเป็นต้องหยุดกลางคันระหว่าง rebase เพื่อแก้ conflict แบบ Git หรือ Mercurial แม้จะแก้ไขหรือลบ commit, jj ก็จะ rebase commit ลูกหลานทั้งหมดให้โดยอัตโนมัติ และต่างจาก Git rebase ตรงที่จัดการ child หลายตัวได้เหมือน Mercurial evolve
    คำสั่งพื้นฐานสำหรับจัดการประวัติ commit ก็ดีเช่นกัน ใช้ jj move|restore เพื่อย้ายหรือคัดลอกการเปลี่ยนแปลงจาก commit หนึ่งไปอีก commit, ใช้ jj split เพื่อแยก commit และใช้ jj rebase เพื่อย้าย commit เพราะ ทุกอย่างอยู่ในประวัติ commit โดยไม่มี working tree หรือ index จึงจัดการได้ด้วยคำสั่งและ flag ชุดเดียวกัน
    operation log ก็ยอดเยี่ยม ทำให้ย้อนกลับงานส่วนใหญ่ได้โดยไม่มีปัญหา ต่างจาก Git ที่ถ้าจะแก้ rebase ที่พังหรือ commit --amend ที่ผิด ต้องไปคุ้ยหา commit ที่ถูกต้องใน reflog แล้วแก้ ref ด้วยมือ
    สิ่งที่ไม่สะดวกที่สุดคือบางครั้ง automatic working-copy commit พยายาม commit ไฟล์ที่ไม่ต้องการเข้าไปด้วย และไม่มี rename detection จึงจัดการ merge ได้ไม่สง่างามเท่า Git ถึงอย่างนั้น commit ที่พังก็แก้ได้ค่อนข้างง่ายด้วย jj split|restore และนักพัฒนา jj เองก็กำลังคิดเรื่องปัญหา rename อยู่

  • ดีใจตรงที่แม้ผลลัพธ์ของงานจะเกิด conflict ก็ยังบันทึกข้อมูลนั้นลงใน commit และถือว่างานสำเร็จ จากนั้นค่อยมาแก้ conflict ภายหลังได้ ช่วงประมาณ 10 ปีที่ผ่านมาได้ทำงานกับอัลกอริทึม collaborative editing และในอุดมคติ อยากให้เครื่องมืออย่าง Git ถูกแทนที่ด้วย แนวทางที่อิง CRDT ในที่สุด
    หากใช้ CRDT ก็จะทำ pair programming ด้วยเครื่องมือเดียวกันได้ และจัดการ merge ซับซ้อนอย่าง self-conflict ที่อาจเกิดใน Git ได้ดีกว่า เป็นโมเดลที่ทรงพลังกว่าด้วย
    อย่างไรก็ตาม text CRDT สมัยใหม่จะแก้การแก้ไขพร้อมกันให้โดยอัตโนมัติแบบไม่มี conflict แต่ในการทำงานร่วมกันบนโค้ดแบบ offline โดยทั่วไปเรามักต้องการให้ conflict ปรากฏออกมาเพื่อให้มนุษย์แก้เอง CRDT มีข้อมูลประวัติการแก้ไขมากกว่า Git ดังนั้นในทางทฤษฎีน่าจะทำได้ แต่ถ้าจะทำให้ถูกต้อง คงต้องใส่ตัว conflict เข้าไปใน data model ของไฟล์ข้อความเอง และยังไม่แน่ใจว่าจะเข้ากับ editor สมัยใหม่ได้อย่างไร
    ฟังดูเหมือน jj ค้นพบกลเม็ดแบบเดียวกัน จึงคาดหวังว่าจะทำงานได้ดีแค่ไหนในทางปฏิบัติ รู้สึกเหมือนเข้าใกล้ความฝันของ code repository ที่อิง CRDT ไปอีกก้าว

    • น่าลองดู Pijul สิ่งที่พูดถึงส่วนใหญ่ในที่นี้แทบจะถูก implement ไว้แล้ว Pijul ทำงานอยู่บน patch ซึ่งเป็น CRDT และถือว่า conflict เป็นแนวคิดระดับ first-class
    • สงสัยว่าไม่เคยรู้สึกถึงคุณค่าของ git bisect เลยหรือ
      ถ้ามี bug ที่ reproduce ได้และสาเหตุซับซ้อน การหาให้เจอว่า commit ไหนเป็นตัวนำ bug เข้ามา แล้วดูว่าการเปลี่ยนแปลงอะไรเป็นสาเหตุน่าจะมีประโยชน์ อย่างน้อยก็ช่วยให้จับทางแรกได้ว่าควรแก้อะไร
      ปัจจุบัน git bisect ทำงานได้ดีที่สุดเมื่อทุก commit build และ run ได้ หากมี commit ที่มี conflict marker อยู่จน build หรือ run ไม่ได้ ก็จะต้องแทรกแซงด้วยมือมากขึ้นมาก
      สงสัยว่าจะปรับฟีเจอร์ที่เทียบเท่ากับ git bisect ให้เข้ากับ scenario แบบนี้ได้อย่างไร การแค่ scan หา string ของ conflict marker อาจไม่เหมาะ เพราะเอกสารอาจอธิบาย conflict marker อยู่ หรือใน markup language บางแบบ ======= ก็อาจถูกใช้เป็นเส้นใต้ได้อย่างถูกต้องตาม syntax
    • อยากรู้ว่าในความเป็นจริงมันจะพัฒนาไปอย่างไร
      ดูเหมือนจะขัดกับแนวคิดที่ว่าประวัติ source management เป็นผลงานที่มีความหมาย และชุด patch ควรถูกจัดระเบียบให้เป็นลำดับของการเปลี่ยนแปลงที่ค่อยเป็นค่อยไปและเป็น atomic ก่อนจะออกจากเครื่องพัฒนา
      อย่างไรก็ตาม นักพัฒนารอบตัวส่วนใหญ่ก็ปฏิบัติกับประวัติ Git เหมือนประวัติ undo ของ editor แบบไร้ขีดจำกัดอยู่แล้ว แนวทางนี้อาจยิ่งตอกย้ำข้อเท็จจริงนั้น
      อยากรู้ว่ามองว่าประวัติระยะยาวจะทำงานอย่างไร และจะมีประโยชน์มากขึ้นหรือน้อยลงเมื่อเทียบกับตอนนี้

  • การที่ สำเนางานถูกคอมมิตอัตโนมัติ ตอนแรกอาจดูดี แต่มีหลายสถานการณ์ที่ไม่ดี
    ถ้ามีไฟล์ผลลัพธ์ใหม่เกิดขึ้นแต่ยังไม่ได้ใส่ไว้ใน .gitignore มันก็จะถูกคอมมิตอัตโนมัติ และถ้าเพิ่มไฟล์ ignore ในบรานช์หนึ่งแล้วสลับไปอีกบรานช์ ไฟล์นั้นยังคงอยู่ในสำเนางานแต่ไม่มีใน .gitignore จึงอาจถูกคอมมิตอัตโนมัติได้
    อีกอย่าง การ stage เฉพาะบางไฟล์แล้วคอมมิตนั้นง่ายกว่าการมาแยกคอมมิตทีหลังมาก

    • ผมมองว่าโปรเจกต์นี้กำลังท้าทายความเชื่อทั่วไปที่ว่าการ stage เฉพาะบางไฟล์แล้วคอมมิตง่ายกว่าการแยกคอมมิตทีหลัง
      ผมเองก็มีความคิดนั้นฝังอยู่ในหัว แต่ก็ไม่แน่ใจว่ามันถูกจริงไหม ในทางปฏิบัติเรามักแก้ index แล้ว amend คอมมิตภายหลังอยู่บ่อย ๆ และจริง ๆ ก็สามารถทำล่วงหน้าได้ด้วย
      ถ้าสุดท้ายหลีกเลี่ยงการแก้ไขย้อนหลังไม่ได้อยู่แล้ว บางทีการมี workflow เดียว สำหรับการแก้ไขแบบนี้อาจดีกว่าหรือเปล่า ผมยังไม่ได้ลองใช้ แต่ดูเป็นแนวทางที่จี้ได้ค่อนข้างน่าเชื่อว่าแนวปฏิบัติที่เราถือว่าเป็นเรื่องปกติอาจไม่ได้ช่วยจริงก็ได้
    • คิดเหมือนกัน โดยปกติในไดเรกทอรีโปรเจกต์จะมี ไฟล์เพิ่มเติม อย่างไฟล์ output, โน้ต, สคริปต์ใช้ครั้งเดียว มากกว่า 10 ไฟล์ เวลาใส่ไฟล์ลงคอมมิตก็จะเลือกตามชื่อไฟล์เสมอ ไม่ใช่ใส่ทุกอย่างที่เพิ่งเกิดขึ้นหรือถูกแก้ไข
      ผมไม่มี use case ที่ไฟล์ที่ถูกสร้างหรือแก้ไขทั้งหมดจะต้องเข้าไปอยู่ในคอมมิตเสมอ
      การที่เมื่อสลับไปบรานช์อื่นแล้วไฟล์ยังเหลืออยู่ในสำเนางาน แต่ไม่มีใน .gitignore ผมมองว่าเป็นความล้มเหลวของ Git ควรมีอะไรอย่าง .local.gitignore เพิ่มเข้ามาควบคู่กับ .gitignore ไฟล์ ignore ที่จำเป็นเฉพาะสำหรับผมนั้นพบได้บ่อยมาก และไม่ใช่สิ่งที่ควรอยู่ใน .gitignore ของโปรเจกต์ ถึงจะมีวิธีทำอยู่บ้าง แต่ทุกวิธีล้วนฝืน ๆ ดังนั้นควรมีให้ใช้ง่าย ๆ เป็นค่าเริ่มต้น
    • ปัญหาแรกอาจแก้ได้ด้วยการเปรียบเทียบไฟล์ที่ถูกติดตามอยู่แล้วกับไฟล์ใหม่อย่างง่าย ๆ ไม่ใช่หรือ
      ถึงอย่างนั้นก็น่าสนใจ ผมไม่เคยชอบ staging ของ Git แต่ก็ไม่เคยเจอกรณีที่พูดถึงตรงนี้ เลยเพิ่งเข้าใจว่าจำเป็นต้องมี ขั้นกลาง ระหว่างระบบไฟล์กับคอมมิต
    • จากที่อ่านแค่ README ผมเข้าใจว่า ถ้าเพิ่มไฟล์พวกนั้นลงใน .gitignore โครงสร้างคือมันจะถูกเอาออกจากคอมมิตสำเนางานแบบนิรนามอีกครั้งในการคอมมิตอัตโนมัติครั้งถัดไป
      กระแสที่ไฟล์ไม่ได้ถูกกันไม่ให้เพิ่มตั้งแต่แรก แต่เข้าไปอยู่ในคอมมิตสำเนางานแบบนิรนามแล้วค่อยถูกเอาออกนั้นไม่ค่อย intuitive แต่ถ้าคอมมิตนิรนามนั้นส่วนใหญ่ผู้ใช้มองไม่เห็น ก็น่าจะไม่ต่างกัน
    • ผมไม่ค่อยเข้าใจว่าสิ่งเหล่านี้เป็นปัญหาใน การออกแบบของ jj อย่างไร และก็ไม่ค่อยเข้าใจว่าทำไมการ stage บางไฟล์ถึงง่ายกว่าการแยกคอมมิตทีหลัง
      ดูจากเอกสารแล้ว หลายกรณีที่กังวลถูกพูดถึงไว้อย่างชัดเจน:
      https://github.com/martinvonz/jj/blob/main/docs/git-comparis...

  • ถ้าไม่นับกรณีพิเศษบางอย่าง ผมแทบไม่ได้ใช้ Git จาก command line มาหลายปีแล้ว ในชีวิตประจำวันพึ่งพา integration ใน IDE อย่าง IntelliJ และยากจะเข้าใจว่าทำไมต้องยอมทำเองด้วยมือ
    ใน editor สามารถเลือกเป็นรายบรรทัดเพื่อทำ partial commit ได้ ดูทุกบรานช์ merge และ cherry-pick ได้ commit หรือ amend ได้ pull อัปเดต และแก้ไข tag ทั้งหมดทำได้ในครั้งเดียวด้วย shortcut
    แต่ดูเหมือนที่นี่ผมจะเป็นเสียงส่วนน้อย ยิ่งเมื่อคำนึงถึงบรรยากาศประมาณว่า Git เป็นทักษะจำเป็น โปรแกรมเมอร์ตัวจริงต้องพิมพ์คำสั่งได้แม้หลับตา ก็ยิ่งเป็นแบบนั้น และผมสงสัยว่าทำไม

    • ผมชอบจัดการ ระบบควบคุมเวอร์ชันผ่าน command line มาโดยตลอด และก็คงจะเป็นแบบนั้นต่อไป
      ทักษะนี้ไม่ขึ้นกับสภาพแวดล้อม ต่อให้เข้าไปดู repository บนเครื่องระยะไกลก็เหมือนกับ local ไม่ต้องเรียนรู้วิธีเชื่อม VCS ของแต่ละ editor ใหม่ และยังใช้เครื่องมือที่คุ้นเคยได้เหมือนเดิม
      งานที่ยกตัวอย่างมาก็ทำจาก command line ได้ง่ายพอ ๆ กัน จึงไม่คิดว่า editor integration มีอะไรพิเศษ ถ้าต้องทำงานแปลก ๆ ขั้นสูงอย่างแตะ reflog สุดท้ายก็มีโอกาสสูงที่ต้องเปิด command line อยู่ดี
      แน่นอนว่าผมไม่มีปัญหากับคนที่ใช้ GUI ถ้าใช้เครื่องมือแล้วทำงานได้ productive ก็ไม่ใช่เรื่องให้ตัดสิน แค่ตอบเพราะถามว่าทำไม และไม่ได้อ้างว่าวิธีของผมดีกว่า
    • จากประสบการณ์ IDE integration มักไม่ได้ implement ความสามารถทั้งหมดของ Git CLI อาจจะดีขึ้นแล้วก็ได้ แต่พอเกิน clone/branch/commit/merge พื้นฐาน และจำนวนนักพัฒนากับบรานช์เพิ่มขึ้นนิดหน่อย สุดท้ายเวลาจะแก้ปัญหาก็ต้องกลับไปใช้ Git CLI
    • ไม่รู้ว่าเป็นโปรแกรมเมอร์ตัวจริงไหม แต่มีความกลัวแบบไม่มีเหตุผลว่า Git GUI อาจทำอะไรผิด ใน IntelliJ ผมก็จัดการ Git โดยเปิด CLI ในตัว นิสัยเก่า ๆ ไม่ตายง่าย ๆ
    • หลายคนที่เพิ่งเริ่มใช้ Git ไม่เข้าใจว่า Git ทำงานอย่างไร นั่นคือไม่เข้าใจว่าคอมมิตกับบรานช์คืออะไร และทำอะไรได้บ้าง แล้วก็โทษเครื่องมือ CLI พร้อมคาดหวังว่าถ้าใช้ GitHub Desktop แล้วทุกอย่างจะเข้าใจเอง
      บริบทที่พบบ่อยที่สุดเวลาคนพูดว่า “ต้องเรียน Git CLI” ก็คือกรณีนี้
      เมื่อไม่กี่วันก่อนก็มีตัวอย่างที่เสนอให้ใช้ GitHub Desktop เพื่อจะได้ไม่ต้องเรียนคำสั่ง Git: https://www.reddit.com/r/learnprogramming/comments/15b7pra/s...
    • ในทีมมีคนที่เข้าใจ Git อยู่แค่สองประเภทเท่านั้น คือ คนที่ใช้ CLI กับคนที่เริ่มกดปุ่มไปเรื่อย ๆ โดยไม่เข้าใจ Git

  • ด้วยแนวทางที่ชูความเข้ากันได้กับ Git เป็นอันดับแรก ทำให้ Jujutsu ดูเป็น ผู้ท้าชิงที่จะมาแทน Git ที่แข็งแกร่งกว่าสิ่งที่เคยเห็นมาจนถึงตอนนี้
    หลังจากอ่านคำอธิบายเรื่องความเข้ากันได้กับ Git สิ่งที่สงสัยคือ ดูเหมือนจะเน้นกรณีใช้งานที่ผู้ใช้ Jujutsu เข้าถึงรีโพซิทอรี Git ที่โฮสต์บน GitHub ฯลฯ ด้วย jj เป็นหลัก เลยสงสัยว่ากลับกันแล้ว รองรับวิธีเข้าถึงรีโพซิทอรี Jujutsu แบบเนทีฟด้วย Git ด้วยหรือไม่
    นักพัฒนาส่วนใหญ่คุ้นเคยกับ Git CLI อยู่แล้ว ในการใช้งานจริงน่าจะมีนักพัฒนาที่ใช้ jj และ Git ร่วมกันบน codebase เดียวกัน หรือไม่ก็สงสัยว่าสถานการณ์ใช้งานจริงคือ เพื่อให้เข้าถึงได้ด้วย CLI ทั้งสองฝั่ง จึงใช้ Git เป็น backend repository เสมอ แทนที่จะใช้ฐานข้อมูล Jujutsu แบบเนทีฟหรือเปล่า

    • ตาม footnote ใน README ตอนนี้แทบไม่มีเหตุผลเชิงปฏิบัติที่จะใช้ native backend
      backend นี้มีอยู่เป็นหลักเพื่อรับประกันว่าในอนาคตจะสามารถใส่ฟีเจอร์ที่เพิ่มเข้าไปใน Git backend ได้ยากได้
    • น่าจะมีความคาดหวังว่าจะใช้ Jujutsu เป็น frontend ของรีโพซิทอรี Git เสมอ หรือไม่ก็ใช้รีโพซิทอรีระยะไกลที่อิงกับ Jujutsu เต็มรูปแบบ
      ถ้าจะทำงานและมีส่วนร่วมในโปรเจกต์ที่ใช้ Jujutsu อยู่แล้ว ก็สมเหตุสมผลที่ผมจะปรับตัวให้เข้ากับโปรเจกต์ ไม่ใช่ให้โปรเจกต์มาปรับเข้ากับ workflow ของผม

  • ด้วยแนวทาง ให้ความเข้ากันได้กับ Git มาก่อน ทำให้ Jujutsu ดูแข็งแกร่งกว่าผู้ท้าชิงที่จะมาแทน Git ที่เคยเห็นมาจนถึงตอนนี้
    สงสัยเรื่องการจัดการ conflict อยู่ รู้ว่า pmeunier ใส่ใจกับการทำ patch theory ให้เป็นรูปแบบทางการสำหรับ Pijul อย่างมาก และแนวคิดเรื่อง patch/conflict ที่ไม่ sound หรือมีปัญหาอาจนำไปสู่ปัญหาใหญ่ได้ เหมือนว่าปัญหาด้านประสิทธิภาพของ Darcs ก็เกิดจากแบบนั้นหรือเปล่า
    ถ้าหน้าเปรียบเทียบบนวิกิของรีโพซิทอรีอธิบายการจัดการ conflict ของ Pijul ให้ละเอียดกว่าแค่บอกว่า “คล้ายกัน” อีกหน่อยก็คงดี

    • มีคำอธิบายที่ละเอียดขึ้นอีกนิดที่นี่: https://github.com/martinvonz/jj/blob/main/docs/technical/co...
      การเก็บ conflict ในเชิงสัญลักษณ์ด้วยวิธีนี้ทำให้ภายหลังสามารถสร้าง conflict ขึ้นมาใหม่ และแม้แต่แก้ conflict บางอย่างได้อัตโนมัติ แต่ไม่ได้ครอบคลุมไปถึงปัญหาการแก้เนื้อหาของ conflict จริง ๆ
      ถ้ามีใคร implement ได้ ก็น่าจะใช้ Pijul เป็น jj backend เพื่อให้ได้ข้อดีของทั้งสองฝั่ง

  • การ replicate อย่างปลอดภัย ผ่าน rsync, Dropbox, distributed file system ฟังดูดี ช่วงนี้เริ่มเอนเอียงไปทางระบบที่เป็นมิตรกับการ sync แบบเรียบง่ายมากขึ้นเรื่อย ๆ
    เพราะโยนไปไว้ที่ไหนด้วยเครื่องมืออะไรก็ทำงานได้เลย เครื่องมือใหม่ที่เลือกแนวทางแบบนี้เป็นเรื่องน่ายินดีเสมอ

    • ถ้าอธิบายส่วนนี้เพิ่มได้ก็คงดี
      เคยได้ยินว่ามีปัญหาแบบนี้ แต่ยังไม่เคยเจอเอง สงสัยว่าเกิด race condition แบบไหนระหว่าง Git กับเครื่องมืออย่าง rsync/Dropbox จึงทำให้เป็นปัญหา

  • ดีใจที่ working copy ถูก commit โดยอัตโนมัติ เป็นฟีเจอร์ที่ควรมีมานานแล้ว
    ขอปรบมือให้ Martin ที่ทุ่มแรงสร้างเครื่องมือที่สง่างามนี้