Bandingkan Teks

Cara perbandingan dihitung

Kedua teks dipecah menjadi baris, lalu baris yang sama di keduanya dicari sebagai longest common subsequence - gagasan yang sama dengan dasar perintah diff di Unix. Semua yang ada di subsequence itu tetap di tempatnya; sisanya dilaporkan sebagai dihapus dari kiri atau ditambahkan di kanan. Jika penghapusan dan penambahan berakhir bersebelahan, keduanya dipasangkan dan ditampilkan sebagai perubahan, bukan dua kejadian yang tidak berhubungan.

Setiap pasangan yang berubah kemudian diperiksa sekali lagi di tingkat kata, sehingga baris panjang yang hanya berubah satu angkanya akan menyorot angka itu saja, bukan mewarnai seluruh baris merah. Inilah bedanya diff yang bisa dibaca dengan diff yang harus dipelototi, dan inilah alasan alat berbasis baris terasa kurang membantu untuk tulisan dan file konfigurasi.

Sebelum semua itu, baris-baris identik di awal dan akhir dipangkas lebih dulu. Dua file seribu baris yang hanya berbeda di satu tempat pun akhirnya dibandingkan sebagai beberapa baris saja, yang lebih cepat sekaligus lebih jelas.

Saat dua baris yang tampak sama ditandai berbeda

Ini kejutan paling umum, dan penyebabnya selalu karakter yang tidak terlihat. Spasi di akhir baris adalah biang yang paling sering, itulah sebabnya opsi mengabaikannya aktif secara bawaan. Berikutnya akhir baris: file yang ditulis di Windows mengakhiri baris dengan carriage return dan line feed, file yang ditulis di macOS atau Linux hanya dengan line feed, dan diff yang membandingkan byte mentah akan menganggap setiap baris berubah.

Setelah itu ada tab lawan deretan spasi, yang bisa disatukan dengan opsi abaikan spasi; spasi tak terputus yang disisipkan pengolah kata dan sebagian halaman web sebagai pengganti spasi biasa; tanda kutip melengkung dan tanda pisah yang diganti oleh koreksi otomatis; dan byte order mark yang tersembunyi di awal baris pertama. Salah satu saja dari ini membuat dua baris yang tampak sama di layar benar-benar berbeda di dalam file.

Batas ukuran

Longest common subsequence berkompleksitas kuadratik: membandingkan m baris dengan n baris berarti mengisi tabel m kali n. Untuk beberapa ratus baris itu sepele, tetapi sepuluh ribu lawan sepuluh ribu berarti seratus juta sel, dan halaman akan berhenti merespons selama mengisinya.

Karena itu perbandingan diberi anggaran empat juta sel setelah prefiks dan sufiks yang sama dipangkas, dan perbandingan yang akan melebihinya ditolak dengan pesan alih-alih dicoba. Dalam praktiknya, file beberapa ribu baris tetap dibandingkan seketika selama isinya secara umum mirip, dan hanya dua dokumen besar yang benar-benar tidak berhubungan yang mencapai batas. Jika itu terjadi, alat yang tepat adalah diff baris perintah yang bisa memproses secara streaming.

Berdampingan atau unified

Tampilan berdampingan menaruh kedua versi di kolomnya masing-masing dan lebih cocok untuk tulisan, terjemahan, dan apa pun yang ingin Anda baca sebagai teks utuh. Tampilan unified menyelang-nyelingkan keduanya dengan penanda, format yang dipakai patch dan code review, dan lebih mudah diikuti saat perubahannya kecil dan tersebar di file yang panjang.

Tidak ada tampilan yang mengubah hasil perhitungan; keduanya hanya dua cara menyajikan hasil yang sama.

Algoritma di balik sebuah diff

Pendekatan klasiknya, yang dipublikasikan Eugene Myers pada 1986, mencari edit script terpendek antara dua rangkaian - himpunan penyisipan dan penghapusan paling sedikit yang mengubah yang satu menjadi yang lain. Inilah yang dipakai perintah diff di Unix dan implementasi bawaan Git, dan ia optimal dalam arti menghasilkan perubahan sesedikit mungkin.

Perubahan paling sedikit belum tentu paling mudah dibaca. Myers bisa menyandingkan baris-baris yang sebenarnya tidak berkaitan tetapi kebetulan sama - kurung kurawal penutup di sini, baris kosong di sana - sehingga diff-nya menyelang-nyelingkan dua fungsi, alih-alih menunjukkan satu fungsi dihapus dan satu lagi ditambahkan. Algoritma patience milik Git mengatasi hal ini dengan berpegang pada baris yang muncul tepat satu kali di kedua versi, lalu bekerja secara rekursif di antara titik-titik pegangan itu, dan hasilnya biasanya cocok dengan apa yang dianggap pembaca sebagai padanan yang sebenarnya.

Algoritma histogram, yang kini menjadi alternatif yang direkomendasikan Git, memperluas patience dengan heuristik frekuensi dan lebih cepat pada berkas besar. Kalau diff dalam code review terlihat tidak masuk akal, menyetel diff.algorithm ke histogram sering kali menghasilkan tampilan yang jauh lebih jelas dari dua berkas yang persis sama.

Perbandingan dua arah dan penggabungan tiga arah

Membandingkan dua berkas menjawab pertanyaan apa yang berubah. Penggabungan butuh masukan ketiga - leluhur bersama - sebab tanpa itu tidak ada cara mengetahui sisi mana yang mengubah suatu baris dan sisi mana yang sekadar mempertahankan versi aslinya. Itulah sebabnya sistem kontrol versi menyimpan merge base, dan sebabnya perkakas merge tiga arah menampilkan tiga panel.

Konflik muncul ketika kedua sisi mengubah bagian yang sama relatif terhadap leluhur tadi. Selebihnya digabungkan otomatis, termasuk perubahan yang bersebelahan tetapi tidak bertumpang tindih, dan itulah sebabnya dua orang bisa menyunting berkas yang sama seharian tanpa konflik lalu bertabrakan hanya pada satu baris.

Memahami hal ini mengubah cara Anda menyelesaikan konflik. Penanda di berkas yang berkonflik menunjukkan versi Anda dan versi mereka, tetapi pertanyaan yang benar-benar berguna adalah apa yang hendak dilakukan masing-masing sisi relatif terhadap versi dasarnya - dan git checkout --conflict=diff3 menambahkan versi dasar itu ke dalam penanda, yang biasanya membuat penyelesaiannya jadi jelas, bukan sekadar menebak di antara dua pilihan.

Membandingkan hal-hal yang bukan baris teks

Perbandingan berbasis baris mengandaikan batas antarbaris punya makna. JavaScript yang diminifikasi, payload JSON dalam satu baris, dan paragraf prosa yang panjang sama-sama mematahkan andaian itu: perubahan satu karakter membuat seluruh baris dilaporkan berbeda. Merapikan format kedua sisi lebih dulu mengembalikan struktur yang dibutuhkan diff, dan untuk JSON, bentuk kanonik - kunci terurut, indentasi seragam - membuat perbandingannya bermakna, bukan kebetulan belaka.

CSV punya masalah sebaliknya: diff berbasis baris tetap jalan, tetapi melaporkan pertukaran urutan kolom sebagai perubahan pada setiap baris. Mengurutkan dulu berdasarkan kolom kunci, atau memakai perkakas yang paham CSV, memisahkan perubahan yang Anda pedulikan dari derau.

Format biner dan yang mendekati biner butuh konverternya sendiri. Berkas .docx sebenarnya zip berisi XML, notebook adalah JSON dengan keluaran yang tertanam di dalamnya, dan PDF sebagian besar tidak tembus pandang. Git mendukung filter textconv yang mengubah berkas menjadi teks sebelum dibandingkan, dan lewat cara inilah tim mendapatkan diff yang terbaca untuk dokumen dan notebook tanpa harus menyimpan salinan kedua.

Membaca diff buatan orang lain

Diff yang enak ditinjau sebagian besar ditentukan oleh apa yang tidak ada di dalamnya. Derau format - formatter yang dijalankan pada satu berkas, akhir baris yang berubah, penyortir import yang diterapkan - mengubur tiga baris yang penting di bawah tiga ratus baris yang tidak penting, dan obat yang biasa dipakai adalah memisahkan commit mekanis dari commit yang substansial, supaya keduanya bisa dibaca dengan kecepatannya masing-masing.

Kalau toh Anda tetap menerima diff yang tercampur, perbandingan yang mengabaikan spasi adalah jalan tercepat untuk menembusnya: git diff -w, atau opsi abaikan yang tersedia di sini. Nyalakan lagi sebelum menyetujui, karena pada sebagian berkas spasi itu adalah isi - indentasi Python, struktur YAML, tab pada Makefile, dan setiap pengujian yang memeriksa keluaran secara persis.

Perkara lain yang layak ditangani secara sengaja adalah penggantian nama dalam jumlah besar. Berkas yang dipindahkan sekaligus disunting akan tampak sebagai satu penghapusan ditambah satu penambahan, kecuali perkakasnya mengenali penggantian nama itu; flag -M milik Git, atau antarmuka peninjauan yang memahami penggantian nama, mengembalikan diff seribu baris menjadi sepuluh baris yang benar-benar berubah.

Membandingkan teks sebagai pekerjaan penyuntingan

Tidak semua diff berurusan dengan kode. Membandingkan dua draf kontrak, dua terjemahan, atau sebuah dokumen sebelum dan sesudah disunting adalah pemakaian yang lazim, dan tampilan berdampingan memang ada untuk itu: Anda ingin membaca kedua teks sebagai teks, bukan sebagai patch.

Untuk prosa, penyorotan pada tingkat kata membawa hampir seluruh manfaatnya, karena kalimat yang ditulis ulang tampil sebagai kalimat yang ditulis ulang, bukan sebagai satu baris yang dihapus dan satu baris yang ditambahkan. Perkakas yang melakukan ini dengan baik di dalam satu baris itulah yang dirasakan orang benar-benar berguna untuk pekerjaan penyuntingan, dan karena itu pula perbandingan di sini menjalankan lintasan kedua pada tingkat kata di dalam setiap pasangan baris yang berubah.

Ada dua catatan praktis untuk dokumen. Teks yang ditempel dari pengolah kata kerap membawa tanda kutip melengkung, tanda pisah en, dan spasi tanpa pemisah yang tidak ada pada salinan satunya, sehingga perbedaan muncul padahal teksnya terlihat sama persis. Lalu, dokumen yang diekspor dua kali dari sumber yang sama pun bisa berbeda hanya pada pemenggalan barisnya, dan itulah sebabnya menyeragamkan akhir baris sebelum membandingkan menghemat banyak kebingungan.