เปรียบเทียบ สองไฟล์

“Diffs” เป็นภาษากลางของการเปลี่ยนแปลง เป็นเรื่องเล่าที่กระชับซึ่งบอกคุณว่า อะไร เคลื่อนไหวระหว่างสองเวอร์ชันของสิ่งหนึ่ง — ซอร์สโค้ด ร้อยแก้ว ชุดข้อมูล — โดยไม่ต้อง บังคับให้คุณอ่านทุกอย่างอีกครั้ง เบื้องหลังสัญลักษณ์ไม่กี่ตัวนั้น (+, -, @@) มีสแต็กของอัลกอริทึม ฮิวริสติก และรูปแบบที่ลึกซึ้ง ที่สร้างสมดุลระหว่างความเหมาะสมที่สุด ความเร็ว และความเข้าใจของมนุษย์ บทความนี้เป็นการเดินทางเชิงปฏิบัติ จากอัลกอริทึมสู่เวิร์กโฟลว์ของ diffs: วิธีการคำนวณ วิธีการจัดรูปแบบ วิธีที่ เครื่องมือผสานใช้ และวิธีปรับแต่งเพื่อการตรวจสอบที่ดีขึ้น ตลอดทาง เราจะอ้างอิง การกล่าวอ้างในแหล่งข้อมูลหลักและเอกสารทางการ — เพราะรายละเอียดเล็กๆ น้อยๆ (เช่น การนับช่องว่าง หรือไม่) มีความสำคัญจริงๆ

“diff” คืออะไรกันแน่

อย่างเป็นทางการ diff อธิบาย สคริปต์แก้ไขที่สั้นที่สุด (SES) เพื่อแปลง ลำดับ “เก่า” เป็น “ใหม่” โดยใช้การแทรกและการลบ (และบางครั้งการแทนที่ ซึ่งสามารถจำลองเป็นการลบ+แทรก) ในทางปฏิบัติ diff ที่โปรแกรมเมอร์ส่วนใหญ่เผชิญคือแบบบรรทัด แล้วจึงปรับแต่งเป็นคำหรืออักขระเพื่อให้อ่านง่ายขึ้น ผลลัพธ์ที่เป็นที่ยอมรับคือรูปแบบ บริบท และ รวม ; แบบหลัง — สิ่งที่คุณมักจะเห็นในการตรวจสอบโค้ด — บีบอัดผลลัพธ์ด้วยส่วนหัวที่กระชับ และ “hunks” ซึ่งแต่ละส่วนจะแสดงพื้นที่ใกล้เคียงของบริบทรอบๆ การเปลี่ยนแปลง รูปแบบรวม ถูกเลือกผ่าน -u/--unified และเป็นมาตรฐานโดยพฤตินัย สำหรับการแพตช์; patch โดยทั่วไปจะได้รับประโยชน์จากบรรทัดบริบท เพื่อใช้การเปลี่ยนแปลงอย่างมีประสิทธิภาพ

คู่มือ GNU diff จัดทำรายการสวิตช์ที่คุณใช้เมื่อต้องการ สัญญาณรบกวนน้อยลงและสัญญาณมากขึ้น — การละเว้นช่องว่าง การขยายแท็บเพื่อการจัดตำแหน่ง หรือการขอ สคริปต์แก้ไข “น้อยที่สุด” แม้ว่าจะช้ากว่าก็ตาม (การอ้างอิงตัวเลือก) ตัวเลือกเหล่านี้ไม่ได้เปลี่ยนความหมายของความแตกต่างของไฟล์สองไฟล์ แต่เปลี่ยน ว่าอัลกอริทึมค้นหาสคริปต์ที่เล็กกว่าอย่างจริงจังเพียงใดและผลลัพธ์นำเสนอต่อมนุษย์อย่างไร

จาก LCS ถึง Myers: diffs คำนวณอย่างไร

diffs ข้อความส่วนใหญ่สร้างขึ้นจากนามธรรม ลำดับย่อยร่วมที่ยาวที่สุด (LCS) การเขียนโปรแกรมไดนามิกแบบคลาสสิกแก้ปัญหา LCS ในเวลาและพื้นที่ O(mn) แต่ นั่นช้าเกินไปและใช้หน่วยความจำมากเกินไปสำหรับไฟล์ขนาดใหญ่ อัลกอริทึมของ Hirschberg แสดงวิธีคำนวณการจัดตำแหน่งที่เหมาะสมที่สุดใน พื้นที่เชิงเส้น (ยังคง เวลา O(mn)) โดยใช้การแบ่งและพิชิต ซึ่งเป็นเทคนิคการประหยัดพื้นที่พื้นฐานที่ มีอิทธิพลต่อการใช้งาน diff ในทางปฏิบัติ

สำหรับความเร็วและคุณภาพ ความก้าวหน้าคือ อัลกอริทึมของ Eugene W. Myers ปี 1986ซึ่งค้นหา SES ในเวลา O(ND) (N ≈ จำนวนบรรทัดทั้งหมด, D ≈ ระยะห่างการแก้ไข) และพื้นที่เกือบเชิงเส้น Myers จำลองการแก้ไขใน “กราฟการแก้ไข” และก้าวไปตาม ขอบเขตที่ไปได้ไกลที่สุด ให้ผลลัพธ์ที่ทั้งเร็วและใกล้เคียง กับค่าต่ำสุดในการตั้งค่า diff แบบบรรทัด นั่นคือเหตุผลที่ “Myers” ยังคงเป็นค่าเริ่มต้นในเครื่องมือมากมาย

นอกจากนี้ยังมีตระกูล Hunt–Szymanski ซึ่งเร่งความเร็ว LCS เมื่อมีตำแหน่งที่ตรงกันน้อย (โดยการจัดทำดัชนีการจับคู่ล่วงหน้าและไล่ตาม ลำดับย่อยที่เพิ่มขึ้น) และในอดีตเชื่อมโยงกับตัวแปร diff ในยุคแรก อัลกอริทึมเหล่านี้ให้ความกระจ่างเกี่ยวกับข้อดีข้อเสีย: ในอินพุตที่มีการจับคู่แบบกระจัดกระจาย พวกมันสามารถทำงานได้ เร็วกว่ากำลังสอง สำหรับภาพรวมของผู้ปฏิบัติงานที่เชื่อมโยงทฤษฎีและการใช้งาน โปรดดู บันทึกของ Neil Fraser.

เมื่อ “เหมาะสมที่สุด” ไม่สามารถอ่านได้: กลยุทธ์ความอดทนและฮิสโตแกรม

Myers มุ่งเป้าไปที่สคริปต์แก้ไขที่น้อยที่สุด แต่ “น้อยที่สุด” ≠ “อ่านง่ายที่สุด” บล็อกขนาดใหญ่ ที่จัดลำดับใหม่หรือซ้ำซ้อนสามารถหลอกอัลกอริทึม SES บริสุทธิ์ให้จัดตำแหน่งที่ไม่เหมาะสมได้ เข้าสู่ patience diffซึ่งให้เครดิตกับ Bram Cohen: มันยึดตาม บรรทัดที่ไม่ซ้ำกันและมีความถี่ต่ำ เพื่อ ทำให้การจัดตำแหน่งมีเสถียรภาพ ซึ่งมักจะสร้าง diffs ที่มนุษย์พบว่าสะอาดกว่า — โดยเฉพาะในโค้ดที่มี ฟังก์ชันที่ย้ายหรือบล็อกที่จัดระเบียบใหม่ เครื่องมือมากมายเปิดเผยสิ่งนี้ผ่านตัวเลือก “ความอดทน” (เช่นdiff.algorithm).

Histogram diff ขยายความอดทนด้วยฮิสโตแกรมความถี่เพื่อจัดการกับองค์ประกอบที่เกิดขึ้นน้อยได้ดีขึ้นในขณะที่ ยังคงความเร็ว (ได้รับความนิยมใน JGit) หากคุณเคยพบว่า --histogram สร้าง hunks ที่ชัดเจนขึ้นสำหรับไฟล์ที่มีเสียงดัง นั่นเป็นไปตามการออกแบบ ใน Git สมัยใหม่ คุณสามารถเลือกอัลกอริทึมได้ทั่วโลกหรือต่อการเรียกใช้:git config diff.algorithm myers|patience|histogram หรือ git diff --patience.

ความชัดเจนระดับคำ การควบคุมช่องว่าง และการเน้นโค้ดที่ย้าย

diffs แบบบรรทัดมีความกระชับแต่อาจปิดบังการแก้ไขเล็กๆ น้อยๆ ได้ diffs ระดับคำ (--word-diff) จะระบายสีการเปลี่ยนแปลงภายในบรรทัดโดยไม่ทำให้การตรวจสอบท่วมท้นไปด้วย การแทรก/การลบทั้งบรรทัด — เหมาะสำหรับร้อยแก้ว สตริงยาว หรือบรรทัดเดียว

ช่องว่างสามารถท่วมท้น diffs หลังจากการจัดรูปแบบใหม่ ทั้ง Git และ GNU diff ให้คุณ ละเว้นการเปลี่ยนแปลงช่องว่าง ในระดับต่างๆ และ ตัวเลือกช่องว่างของ GNU diff (-b, -w, -B) ช่วยเมื่อตัวจัดรูปแบบทำงาน; คุณจะเห็น การแก้ไข เชิงตรรกะ แทนที่จะเป็นเสียงรบกวนจากการจัดตำแหน่ง

เมื่อโค้ดย้ายไปทั้งชุด Git สามารถ เน้นบล็อกที่ย้าย ด้วย --color-moved ซึ่งแยก “ย้าย” ออกจาก “แก้ไข” ด้วยสายตา ซึ่งช่วยให้ ผู้ตรวจสอบตรวจสอบว่าการย้ายไม่ได้ซ่อนการแก้ไขที่ไม่ได้ตั้งใจไว้ ทำให้คงอยู่ผ่าน diff.colorMoved.

Diffs ในบริการของการผสาน: สองทางเทียบกับสามทางและ diff3

diff สองทางเปรียบเทียบสองเวอร์ชันอย่างแน่นอน ไม่สามารถบอกได้ว่าทั้งสอง ฝ่ายแก้ไขบรรทัดฐานเดียวกันหรือไม่ ดังนั้นจึงมักเกิดความขัดแย้งมากเกินไป การผสานสามทาง (ใช้โดย VCS สมัยใหม่) คำนวณ diffs จากบรรพบุรุษร่วมกันไปยังแต่ละฝ่ายแล้วจึงกระทบยอดชุดการเปลี่ยนแปลงทั้งสอง ซึ่งจะช่วยลด ความขัดแย้งที่ผิดพลาดได้อย่างมากและให้บริบทที่ดีขึ้น แกนกลางอัลกอริทึมแบบคลาสสิกที่นี่คือ diff3ซึ่งผสานการเปลี่ยนแปลงจาก “O” (ฐาน) เป็น “A” และ “B” และทำเครื่องหมายความขัดแย้งเมื่อจำเป็น

งานวิชาการและอุตสาหกรรมยังคงทำให้เป็นทางการและปรับปรุงความถูกต้องของการผสาน ตัวอย่างเช่น การผสานสามทางที่ตรวจสอบแล้วเสนอแนวคิดเชิงความหมายของความเป็นอิสระจากความขัดแย้ง ใน Git ประจำวัน กลยุทธ์การผสาน ort สมัยใหม่สร้างขึ้นจากการทำ diff และการตรวจจับการเปลี่ยนชื่อเพื่อสร้างการผสานที่มีความประหลาดใจน้อยลง สำหรับผู้ใช้ เคล็ดลับสำคัญคือ: แสดงบรรทัดฐานในความขัดแย้งด้วย merge.conflictStyle=diff3และรวมบ่อยๆ เพื่อให้ diffs มีขนาดเล็ก

การตรวจจับการเปลี่ยนชื่อและเกณฑ์ของมัน

diffs แบบดั้งเดิมไม่สามารถ “เห็น” การเปลี่ยนชื่อได้เนื่องจากการกำหนดที่อยู่เนื้อหาถือว่าไฟล์เป็น blobs; พวกเขาเห็นเพียงการลบและการเพิ่ม ฮิวริสติกการตรวจจับการเปลี่ยนชื่อ เชื่อมช่องว่างนั้นโดยการเปรียบเทียบความคล้ายคลึงกันระหว่างคู่ที่เพิ่ม/ลบ ใน Git เปิดใช้งาน หรือปรับแต่งผ่าน -M/--find-renames[=<n>] (ค่าเริ่มต้นคือ ~50% ความคล้ายคลึงกัน) ลดค่าลงสำหรับการเคลื่อนไหวที่มีเสียงดังมากขึ้น คุณสามารถ จำกัดการเปรียบเทียบผู้สมัคร ด้วย diff.renameLimit (และ merge.renameLimit ระหว่างการผสาน) หากต้องการติดตามประวัติผ่านการเปลี่ยนชื่อ ให้ใช้ git log --follow -- <path>Git ล่าสุดยังดำเนินการ การตรวจจับการเปลี่ยนชื่อไดเรกทอรี เพื่อเผยแพร่การย้ายโฟลเดอร์ระหว่างการผสาน

diffs ไบนารีและเดลต้า: rsync, VCDIFF/xdelta, bsdiff

ข้อความไม่ใช่สิ่งเดียวที่เปลี่ยนแปลง สำหรับไบนารี คุณมักจะต้องการ การเข้ารหัสเดลต้า — ออกคำสั่งคัดลอก/เพิ่มเพื่อสร้างเป้าหมายจาก แหล่งที่มา อัลกอริทึม rsync เป็นผู้บุกเบิกการทำ diff ระยะไกล ที่มีประสิทธิภาพโดยใช้ checksum แบบหมุนเพื่อจัดตำแหน่งบล็อก ผ่านเครือข่าย ลดแบนด์วิดท์

IETF ได้กำหนดมาตรฐานรูปแบบเดลต้าทั่วไป VCDIFF (RFC 3284)ซึ่งอธิบาย bytecode ของ ADD, COPY และ RUN โดยมี การใช้งานเช่น xdelta3 ที่ใช้สำหรับการแพตช์ไบนารี สำหรับแพตช์ขนาดกะทัดรัดบนไฟล์ปฏิบัติการ bsdiff มักจะสร้างเดลต้าขนาดเล็กมากผ่านอาร์เรย์ต่อท้ายและการบีบอัด เลือกใช้เมื่อขนาดแพตช์ มีความสำคัญและการสร้างสามารถทำได้แบบออฟไลน์

diffs ข้อความนอกเหนือจากซอร์สโค้ด: การจับคู่แบบคลุมเครือและการแพตช์

เมื่อคุณต้องการ การแพตช์ที่แข็งแกร่ง เมื่อเผชิญกับการแก้ไขพร้อมกันหรือบริบทที่ ไม่ตรงกันเล็กน้อย — ลองนึกถึงโปรแกรมแก้ไขหรือระบบการทำงานร่วมกัน — พิจารณา diff-match-patchมันผสมผสานการทำ diff แบบ Myers กับ Bitap การจับคู่แบบคลุมเครือเพื่อค้นหาการจับคู่ที่ใกล้เคียงและใช้แพตช์ “ตามความพยายามที่ดีที่สุด” บวกกับการเร่งความเร็วก่อน diff และการล้างข้อมูลหลัง diff ที่แลกความน้อยที่สุดเล็กน้อยเพื่อให้ได้ผลลัพธ์ที่มนุษย์อ่านง่ายขึ้น สำหรับวิธี รวม diff และแพตช์แบบคลุมเครือในลูปการซิงค์อย่างต่อเนื่อง โปรดดู Differential Synchronizationของ Fraser

diffs ข้อมูลที่มีโครงสร้าง: ตารางและต้นไม้

diffs แบบบรรทัดบน CSV/TSV นั้นเปราะบางเนื่องจากการเปลี่ยนแปลงเซลล์เดียวอาจดูเหมือนการแก้ไขทั้งบรรทัด เครื่องมือ diff ที่รับรู้ตาราง (daff) ถือว่าข้อมูลเป็นแถว/คอลัมน์ ออกแพตช์ที่กำหนดเป้าหมายเซลล์เฉพาะและแสดง การแสดงภาพที่ทำให้การเพิ่ม การลบ และการแก้ไขชัดเจน (ดู R vignette) สำหรับการตรวจสอบอย่างรวดเร็ว ตัวเปรียบเทียบ CSV เฉพาะทางสามารถเน้นการเปลี่ยนแปลงทีละเซลล์และการเปลี่ยนแปลงประเภทได้ พวกมันไม่ได้แปลกใหม่ในเชิงอัลกอริทึม แต่เพิ่ม สัญญาณการตรวจสอบ โดย การเปรียบเทียบโครงสร้างที่คุณสนใจจริงๆ

การปรับแต่ง Git diff ในทางปฏิบัติ: รายการตรวจสอบของผู้ตรวจสอบ

• เลือกอัลกอริทึมที่เหมาะสม: เริ่มต้นด้วย Myers (ค่าเริ่มต้น) ลองใช้ --patience หากการจัดลำดับใหม่หรือบล็อกที่มีเสียงดังทำให้ผลลัพธ์สับสน หรือ --histogram สำหรับ diffs ที่รวดเร็วและอ่านง่ายบนข้อความซ้ำๆ ตั้งค่าเริ่มต้นด้วย git config diff.algorithm ….
• ลดเสียงรบกวน: สำหรับการแก้ไขเฉพาะสไตล์ ให้ใช้แฟล็กช่องว่าง (-b, -w, --ignore-blank-lines) เพื่อมุ่งเน้นไปที่การเปลี่ยนแปลงที่สำคัญ นอก Git โปรดดู การควบคุมช่องว่างของ GNU diff.
• ดูภายในบรรทัด: --word-diff ช่วยสำหรับบรรทัดยาวและร้อยแก้ว
• ตรวจสอบโค้ดที่ย้าย: --color-moved (หรือ diff.colorMoved) แยก “ย้าย” ออกจาก “แก้ไข”
• จัดการการเปลี่ยนชื่อ: เมื่อตรวจสอบการปรับโครงสร้าง ให้เพิ่ม -M หรือปรับเกณฑ์ความคล้ายคลึงกัน (-M90%, -M30%) เพื่อจับ การเปลี่ยนชื่อ; โปรดจำไว้ว่าค่าเริ่มต้นคือประมาณ 50% สำหรับต้นไม้ลึก ให้ตั้งค่า diff.renameLimit.
• ติดตามประวัติผ่านการเปลี่ยนชื่อ: git log --follow -- <path>.

การผสานใช้ diffs อย่างไร (และจะทำอย่างไรเมื่อไม่เป็นเช่นนั้น)

การผสานจะคำนวณ diffs สองรายการ (BASE→OURS, BASE→THEIRS) และพยายามใช้ทั้งสองกับ BASE กลยุทธ์เช่น ort จัดระเบียบสิ่งนี้ในระดับใหญ่ โดยรวมการตรวจจับการเปลี่ยนชื่อ (รวมถึงการย้ายระดับไดเรกทอรี) และ ฮิวริสติกเพื่อลดความขัดแย้ง เมื่อเกิดความขัดแย้ง --conflict=diff3 จะเพิ่มบริบท ฐาน ให้กับเครื่องหมาย ซึ่งมีค่าอย่างยิ่งในการทำความเข้าใจ เจตนา บท Pro Git เกี่ยวกับ การผสานขั้นสูง จะแนะนำรูปแบบการแก้ไข และเอกสารของ Git จะแสดงรายการปุ่มต่างๆ เช่น -X ours และ -X theirsหากต้องการประหยัดเวลาในความขัดแย้งที่เกิดซ้ำ ให้เปิดใช้งาน rerere เพื่อบันทึกและเล่นซ้ำการแก้ไขของคุณ

นอกเหนือจากไฟล์: สถานการณ์ระยะไกลและส่วนเพิ่ม

หากคุณกำลังซิงค์เนื้อหาขนาดใหญ่ผ่านเครือข่าย คุณจะใกล้ชิดกับ rsync โลกมากกว่า diff ในเครื่อง Rsync คำนวณ checksum แบบหมุนเพื่อค้นหาบล็อกที่ตรงกัน จากระยะไกล แล้วจึงถ่ายโอนเฉพาะสิ่งที่จำเป็น สำหรับเดลต้าที่บรรจุแล้ว VCDIFF/xdelta ให้ bytecode มาตรฐานและเครื่องมือที่สมบูรณ์แก่คุณ เลือกใช้เมื่อคุณควบคุมทั้งตัวเข้ารหัสและ ตัวถอดรหัส และหากขนาดแพตช์มีความสำคัญสูงสุด (เช่น เฟิร์มแวร์ over-the-air) bsdiff จะแลกเปลี่ยน CPU/หน่วยความจำ ณ เวลาสร้างสำหรับแพตช์ขนาดเล็กมาก

คำสั้นๆ เกี่ยวกับ “คลุมเครือ” และ “เป็นมิตร”

ไลบรารีเช่น diff-match-patch ยอมรับว่าในโลกแห่งความเป็นจริง ไฟล์ที่คุณกำลังแพตช์อาจมีการเปลี่ยนแปลงไป โดยการรวม diff ที่มั่นคง (มักจะเป็น Myers) กับการจับคู่แบบคลุมเครือ (Bitap) และกฎการล้างข้อมูลที่กำหนดค่าได้ พวกเขาสามารถ ค้นหาสถานที่ที่เหมาะสม เพื่อใช้แพตช์และ ทำให้ diff อ่านง่ายขึ้น — สำคัญอย่างยิ่งสำหรับการแก้ไขร่วมกันและการซิงค์

“เดิมพันบนโต๊ะ” ที่คุณควรจดจำ

1. รู้จักรูปแบบของคุณ diffs แบบรวม (-u/-U<n>) มีขนาดกะทัดรัดและเป็นมิตรกับการแพตช์ เป็นสิ่งที่การตรวจสอบโค้ดและ CI คาดหวัง (การอ้างอิง)
2. รู้จักอัลกอริทึมของคุณ Myers สำหรับการแก้ไขที่น้อยที่สุดอย่างรวดเร็ว (บทความ); ความอดทน/ฮิสโตแกรมเพื่อให้อ่านง่ายขึ้นในการจัดลำดับใหม่หรือบล็อกที่มีเสียงดัง (ความอดทน, ฮิสโตแกรม); Hirschberg สำหรับเคล็ดลับพื้นที่เชิงเส้น (บทความ); Hunt–Szymanski สำหรับการเร่งความเร็วการจับคู่แบบกระจัดกระจาย (บทความ)
3. รู้จักสวิตช์ของคุณ การควบคุมช่องว่าง, word-diff และ color-moved เป็น ตัวคูณการตรวจสอบ (เอกสาร git diff; ตัวเลือกช่องว่างของ GNU)
4. รู้จักการผสานของคุณ สามทางด้วย diff3 -สไตล์ไม่สับสน; ort บวกกับการตรวจจับการเปลี่ยนชื่อช่วยลดการเปลี่ยนแปลง; rerere ช่วยประหยัดเวลา
5. เลือกเครื่องมือที่เหมาะสมสำหรับข้อมูล สำหรับ CSV/ตาราง ให้ใช้ daff; สำหรับไบนารี ให้ใช้ VCDIFF/xdelta หรือ bsdiff.

ภาคผนวก: ตำราอาหารคำสั่งขนาดเล็ก

เพราะความจำของกล้ามเนื้อมีความสำคัญ:

# แสดง diff แบบรวมมาตรฐานพร้อมบริบทเพิ่มเติม
  git diff -U5
  diff -u -U5 a b
  
  # รับความชัดเจนระดับคำสำหรับบรรทัดยาวหรือร้อยแก้ว
  git diff --word-diff
  
  # ละเว้นเสียงรบกวนจากช่องว่างหลังจากการจัดรูปแบบใหม่
  git diff -b -w --ignore-blank-lines
  diff -b -w -B a b
  
  # เน้นโค้ดที่ย้ายระหว่างการตรวจสอบ
  git diff --color-moved
  git config --global diff.colorMoved default
  
  # จัดการการปรับโครงสร้างด้วยการตรวจจับการเปลี่ยนชื่อและติดตามประวัติผ่านการเปลี่ยนชื่อ
  git diff -M
  git log --follow -- <file>
  
  # เลือกอัลกอริทึมเพื่อให้อ่านง่ายขึ้น
  git diff --patience
  git diff --histogram
  git config --global diff.algorithm patience
  
  # ดูบรรทัดฐานในเครื่องหมายความขัดแย้ง
  git config --global merge.conflictStyle diff3

ความคิดปิดท้าย

diffs ที่ยอดเยี่ยมนั้นไม่เกี่ยวกับการพิสูจน์ความน้อยที่สุดมากนัก แต่เกี่ยวกับ การเพิ่มความเข้าใจของผู้ตรวจสอบให้สูงสุด ด้วยต้นทุนทางปัญญาที่น้อยที่สุด นั่นคือเหตุผลที่ ระบบนิเวศได้พัฒนาอัลกอริทึมหลายตัว (Myers, ความอดทน, ฮิสโตแกรม) การนำเสนอหลายรูปแบบ (รวม, word-diff, color-moved) และเครื่องมือที่รับรู้โดเมน (daff สำหรับตาราง, xdelta/bsdiff สำหรับไบนารี) เรียนรู้ข้อดีข้อเสีย ปรับปุ่ม แล้วคุณจะใช้เวลามากขึ้นในการให้เหตุผล เกี่ยวกับ เจตนา และใช้เวลาน้อยลงในการประกอบบริบทจากบรรทัดสีแดงและสีเขียว