Mergiraf - เครื่องมือจัดการการ Merge แบบรู้โครงสร้างไวยากรณ์สำหรับ Git

 (mergiraf.org)
4 คะแนน โดย GN⁺ 2024-11-10 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เครื่องมือสำหรับแก้ไข Git Merge Conflict โดยเข้าใจโครงสร้างต้นไม้ภายในไฟล์เพื่อประสานความต้องการของทั้งสองฝั่งอย่างกลมกลืน
  • สามารถเพิ่มภาษาใหม่ได้แบบประกาศเชิงกำหนด
  • สามารถตั้งค่าให้ใช้ Mergiraf แทนอัลกอริทึม Merge พื้นฐานของ Git ได้
    • ช่วยปรับปรุงคำสั่ง Git เช่น merge, revert, rebase, cherrypick
  • หรือจะคงพฤติกรรมดั้งเดิมของ Git ไว้ แล้วเรียกใช้ Mergiraf เองเมื่อเกิดความขัดแย้งก็ได้

เป้าหมายของ Mergiraf

  • ไม่ซ่อนความขัดแย้ง
    • ฮิวริสติกการ merge ที่รับรู้ไวยากรณ์อาจมองโลกในแง่ดีเกินไปในบางครั้งและถือว่าความขัดแย้งถูกแก้แล้ว
    • หากมีความน่าสงสัย Mergiraf จะพยายามรักษาสภาพที่ดีที่สุดไว้โดยคง conflict marker ไว้ในไฟล์
    • หากแก้ความขัดแย้งทั้งหมดได้ด้วยตัวเอง ก็จะแนะนำให้ตรวจสอบงานไกล่เกลี่ยผ่านคำสั่ง mergiraf review
    • หากการรวมดูเหมือนผิดพลาด สามารถรายงานได้ง่ายด้วย mergiraf report
  • เร็วพอสำหรับการใช้งานแบบโต้ตอบ
    • ยีราฟสามารถวิ่งได้ด้วยความเร็ว 60 กิโลเมตรต่อชั่วโมง
    • งานรวมเวอร์ชันที่แตกแขนงของไฟล์มักเกิดขึ้นเป็นกิจวัตรโดยแทบไม่ทันสังเกต ตราบใดที่ไม่มีความขัดแย้ง
    • Mergiraf พยายามทำงานให้รวดเร็วเพื่อไม่ให้รบกวนเวิร์กโฟลว์
  • เปิดกว้างต่อวิธีอื่น
    • ในหลายกรณี การ merge แบบอิงบรรทัดทำงานได้ดีและไม่จำเป็นต้องมีการจัดการต้นไม้
    • หากการ merge แบบอิงบรรทัดไม่มีความขัดแย้ง Mergiraf จะส่งคืนผลลัพธ์นั้นทันที (เร็วมาก)
    • หากการ merge แบบอิงบรรทัดทำให้เกิดคีย์ซ้ำ Mergiraf จะทำงานเพิ่มเติมเล็กน้อยเพื่อแก้ปัญหาหรือเน้นให้เห็นด้วย conflict marker

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

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

 
2147483647 2024-11-11

ยีราฟสามารถวิ่งได้ด้วยความเร็ว 60 กิโลเมตรต่อชั่วโมงเลยนะ
 
GN⁺ 2024-11-10
ความเห็นจาก Hacker News

  • กำลังทำงานคล้ายกับ SemanticDiff และกำลังเจอปัญหาในการใช้ tree-sitter กับ GumTree

    • tree-sitter ถูกสร้างมาเพื่อการเน้นไวยากรณ์เป็นหลัก จึงวิเคราะห์ไวยากรณ์ได้ไม่แม่นยำนักเมื่อมีการแก้ไขโค้ด
    • GumTree ให้ผลลัพธ์ได้รวดเร็ว แต่ก็มักคืนค่าการจับคู่ที่ผิดพลาดบ่อยครั้ง
    • กำลังเปลี่ยนไปใช้แนวทางที่อิง Dijkstra และได้ผลลัพธ์ที่ดีกว่า

  • ส่วนสถาปัตยกรรมของ Mergiraf อธิบายวิธีการทำงานของเครื่องมือที่ซับซ้อนนี้ได้อย่างลึกซึ้ง

  • เหตุผลที่เลือกยีราฟคือมันมองได้ไกลเพราะความสูง และมีหัวใจใหญ่ที่สุดในบรรดาสัตว์เลี้ยงลูกด้วยนมบนบก

  • วิจารณ์แนวคิดที่อ้างว่าในการแทรกบางกรณี ลำดับไม่สำคัญ

    • ในระดับภาษา ลำดับอาจไม่สำคัญ แต่สำหรับมนุษย์แล้ว ลำดับบางแบบอาจสำคัญ
    • ยกตัวอย่างกรณีที่มี Base เป็น struct Foo; struct Bar; แล้วฝั่ง Left แทรก impl Foo { } ขณะที่ฝั่ง Right แทรก struct Baz; ระหว่างสองบรรทัดนี้ ซึ่งคอมพิวเตอร์อาจมองไม่เห็นความแตกต่าง

  • มองบวกกับการพัฒนา merge driver ของ Git

    • การ merge แบบ 3-way มาตรฐานไม่เข้าใจภาษา จึงอาจก่อปัญหาได้
    • ในโค้ด Python ถ้าสองสาขาที่ต่างกันลบ print คนละตัว ก็อาจทำให้โค้ดที่ได้ไม่ถูกต้อง

  • เมื่อทีมขยายภาษาพื้นฐานให้เข้ากับปัญหาเฉพาะ เครื่องมือที่รับรู้ไวยากรณ์มักเจอปัญหา

    • มีการกล่าวถึงกรณีใช้งานของ macro ใน Rust หรือ "go generate"

  • เป็นไอเดียที่อาจช่วยแก้ความขัดแย้งที่เกี่ยวข้องกับการจัดรูปแบบอัตโนมัติได้

    • สงสัยว่าจะสามารถตรวจจับ semantic conflict ที่เกิดจากการย้ายโค้ดได้หรือไม่

  • ตั้งใจจะลองใช้ Mergiraf และใช้งานร่วมกับ git-absorb อยู่แล้ว

    • อยากให้ทั้งสองเครื่องมือทำงานได้อย่างสมบูรณ์แบบ หรือถูกรวมเข้า Git อย่างเป็นทางการ

  • การรองรับ Python น่าจะมีประโยชน์

    • AST ของ Python ที่อิงการเยื้องบรรทัดดูเหมือนจะทำงานได้ดี

  • แม้การรองรับภาษายังมีจำกัด แต่ก็หวังว่าจะมีการเพิ่มการรองรับภาษาอื่นอีกมากขึ้น