Mengapa Git Autocorrect Terlalu Cepat Bahkan untuk Pembalap Formula One

• help.autocorrect=1 pada Git setelah memperbaiki perintah yang salah ketik hanya menunggu 0,1 detik lalu menjalankannya, sehingga bagi pengguna ini terasa nyaris langsung berjalan tanpa sempat mengonfirmasi atau membatalkan
• Perilaku ini bukan default Git; pada konfigurasi bawaan, Git tidak menjalankan perintah yang tidak dikenal, hanya menampilkan perintah yang mirip lalu keluar
• Dalam diskusi tahun 2008, help.autocorrect diubah dari boolean menjadi waktu tunggu dalam satuan decisecond, sehingga 1 ditafsirkan bukan sebagai true, melainkan sebagai jeda 0,1 detik
• Saat ini help.autocorrect mendukung 0, angka positif, immediate, prompt, dan never; jika ingin menjalankan setelah konfirmasi, prompt adalah pilihan yang lebih aman
• Estimasi perintah Git berbasis Levenshtein distance yang dimodifikasi, dan Scott Chacon mengusulkan patch agar 1 serta string boolean ditangani secara lebih alami

---

Hingga git pushy dijalankan sebagai git push

• Saat @dhh mengetik git pushy, Git menebaknya sebagai git push dan hanya menunggu 0,1 detik sebelum menjalankannya
• 0,1 detik terlalu singkat bagi pengguna untuk membaca perintah, menilai apakah benar, lalu membatalkannya
• Perilaku ini bukan perilaku bawaan Git, melainkan muncul ketika pengaturan help.autocorrect diaktifkan

Perilaku default dan lahirnya help.autocorrect

• Respons default Git adalah tidak menjalankan perintah yang tidak dikenal, melainkan menampilkan kemungkinan perintah berdasarkan kemiripan string lalu keluar
  • Contoh: git pushy dapat ditampilkan sebagai paling mirip dengan perintah push
• Awalnya, untuk perintah yang tidak dikenal, Git hanya merespons “bukan perintah Git”
• Pada 2008, Johannes Schindelin mengusulkan patch kecil yang menelusuri perintah yang dikenal untuk mencari perintah paling mirip, lalu menjalankannya jika hanya ada satu kandidat yang dekat
• Alex Riesen mengajukan patch untuk mengendalikan hal ini lewat pengaturan help.autocorrect, dan pada awalnya pengaturan ini adalah boolean
  • Dalam konfigurasi Git, nilai boolean dapat menafsirkan 1 sebagai true
  • Jadi dalam konteks awal, help.autocorrect=1 bisa tampak seperti nilai untuk mengaktifkan autocorrect

Mengapa 1 menjadi 0,1 detik

• Junio Hamano mengusulkan agar help.autocorrect bukan sekadar boolean, melainkan jumlah decisecond yang harus ditunggu sebelum eksekusi
  • Decisecond adalah satuan 0,1 detik
  • Tujuannya adalah memberi pengguna kesempatan menekan ^C
• Dalam patch yang kemudian diterima, nilai konfigurasi diubah menjadi waktu tunggu
• Akibatnya, help.autocorrect=1 bukan berarti “mengaktifkan fitur”, melainkan “menunggu 1 decisecond, yaitu 0,1 detik, lalu menjalankan”
• Mengapa decisecond dipilih sebagai satuan waktu yang sesuai tidak tercatat dalam diskusi

Nilai konfigurasi yang bisa dipilih saat ini

• Berdasarkan dokumentasi Git, help.autocorrect mendukung nilai berikut
  • 0: nilai default, hanya menampilkan perintah yang disarankan
  • Angka positif: menjalankan perintah yang disarankan setelah decisecond yang ditentukan
  • immediate: langsung menjalankan perintah yang disarankan
  • prompt: menampilkan saran dan meminta konfirmasi apakah akan menjalankannya
  • never: tidak menjalankan maupun menampilkan perintah yang disarankan
• Jika ingin menjalankan setelah konfirmasi, prompt lebih masuk akal bagi kebanyakan pengguna
• Contoh pengaturannya sebagai berikut

git config --global help.autocorrect prompt

• Setelah itu, jika memasukkan perintah seperti git pushy, Git akan meminta konfirmasi [y/N] apakah akan menjalankan push

Cara Git memilih perintah yang mirip

• Git tidak menebak perintah secara asal; mulai dari titik tertentu, Git menganggap perbedaannya terlalu jauh dan tidak mengajukan kandidat
• Contoh perilakunya sebagai berikut
  • git bass cukup dekat dengan rebase, sehingga Git menampilkan konfirmasi eksekusi
  • git bassa dinilai tidak lagi layak dianggap sebagai rebase, sehingga Git tidak menjalankan kandidat
  • git dm menampilkan am dan rm sebagai perintah yang sama-sama mirip
  • git dma cocok dengan satu perintah saja, yaitu am
• Logika ini berbasis algoritma Levenshtein distance yang dimodifikasi
  • Menghitung biaya edit karakter yang diperlukan untuk mengubah satu string menjadi string lain
  • Sebagian operasi diperlakukan lebih mahal daripada operasi lainnya
• Git memiliki cutoff yang di-hardcode; jika biaya terhadap perintah yang dikenal terlalu besar, Git menganggap pengguna salah ketik secara signifikan dan tidak membuat tebakan

Patch untuk mengubah penafsiran 1

• Karena help.autocorrect=1 secara manusiawi nyaris sama dengan immediate, Scott Chacon menulis patch kecil yang menafsirkan 1 sebagai eksekusi langsung, bukan jeda 0,1 detik
• Junio Hamano meminta agar tidak hanya "1" yang diperlakukan khusus, tetapi juga agar nilai string boolean seperti yes, no, true, off ditafsirkan dengan benar
• Versi kedua patch sedang berjalan ke arah yang juga mencakup penanganan string boolean tersebut
• Jika patch diterapkan, kebingungan seputar help.autocorrect dapat berkurang di versi Git mendatang

[GN⁺]

Komentar Hacker News

• Pada era 70-an, Hal Finney sedang berusaha memuat interpreter BASIC untuk Mattel Intellivision ke dalam ROM 2KB, jadi setiap byte benar-benar berharga
  Untuk menandai kesalahan sintaks, semua pesan error dipersingkat menjadi EH?, dan masih lucu membayangkan bahwa dia cukup bangga dengan itu

  • EH? juga terasa cocok sebagai respons parser teks dalam game interactive fiction jadul
    Sedikit terkait, beberapa varian BASIC lama juga menulis perintah PRINT sebagai ?, yang tampaknya lebih ditujukan untuk mengurangi waktu mengetik di REPL daripada menghemat memori
  • Boros sekali. ed memakai satu ? saja untuk semua error, jadi 3 kali lebih hemat
  • Contoh paling awal yang pernah saya lihat untuk respons interpreter Eh? ada di JOSS milik RAND
    [https://en.wikipedia.org/wiki/JOSS#/media/File:JOSS_Session....](https://en.wikipedia.org/wiki/JOSS#/media/File:JOSS_Session.jpg)
    https://en.wikipedia.org/wiki/JOSS
    Memorinya sekitar 5KB, tetapi dibanding Intellivision, mesinnya berbobot sekitar 5.000 pon
  • Cukup keren. Saya tidak tahu Hal adalah seorang peretas komputer pribadi pada masa itu, dan setiap mendengar soal Hal saya selalu langsung teringat Bitcoin
  • Saya menjalankan xordle, turunan Wordle yang menaruh dua puzzle Wordle di satu papan
    Jadi ada kalanya Anda menebak sebuah kata dan kelima hurufnya hijau semua, tetapi tetap bukan salah satu dari dua jawaban yang benar. Dalam kasus seperti itu, saya menampilkan Huh? di sisi kanan, dan orang-orang suka bagian itu

• Akar masalahnya adalah nama pengaturannya buruk
  Kalau pengaturan aslinya dinamai seperti help.autocorrect_enabled sehingga terasa seperti boolean, permintaan agar menerima nilai integer yang ditafsirkan sebagai kelipatan 0,1 detik tentu akan terdengar tidak masuk akal. Sebagai gantinya, mereka perlu membuat pengaturan lain seperti help.autocorrect_accept_after_dsec, dan dsec cukup tidak lazim sehingga siapa pun yang memakainya hampir pasti akan mencari tahu dulu
  Saya selalu meminta hal seperti ini saat code review. Jika bisa ambigu, nama variabel harus memuat satuan. Misalnya int timeout seharusnya menjadi int timeout_msec
  Dalam nama pengaturan, ini 100 kali lebih penting. Pengaturan adalah bagian dari antarmuka publik, jadi nanti tidak bisa diubah lagi

  • Sepemikiran. Hanya saja saya masih bimbang ketika ini bergeser ke sistem tipe
    Dalam konteks C++, aturan praktis saya kurang lebih begini: void FooBar(std::chrono::milliseconds timeout); tidak masalah. Karena itu tanda tangan fungsi, Anda juga melihat tipenya saat membacanya
    Tetapi untuk variabel, timeout saja tidak cukup. Dalam 99% kasus, penggunaan nyatanya akan terlihat seperti auto timeout = gl_timeout; atau FooBar(timeout);
    Karena auto sering dipakai di C++, menelusuri tipe persisnya saat itu penting menjadi cukup merepotkan
    Saat bekerja dengan C++, saya memang memakai IDE atau editor dengan language server, tetapi saya tidak punya waktu untuk hover tiap 5 detik hanya demi memeriksa tipe
  • Betul, dan keadaan makin parah karena mereka memakai satuan 0,1 detik (decisecond), satuan waktu yang seumur hidup hampir tidak pernah benar-benar saya tulis
    Kalau pesannya berbunyi “akan dijalankan dalam 1ms”, saya pasti langsung mengecek pengaturannya
  • Kalau begitu akhirnya jadi seperti systemd, di mana TimoutSec=60 dan TimeoutSec=1min sama-sama bisa dipakai
    Menurut saya malah lebih baik tidak memasukkan satuan ke dalam nama. Namun selain kasus aneh itu, saya sepenuhnya setuju
  • Saya memang melakukan itu, tetapi sulit menghilangkan kesan seperti notasi Hungaria
    Alternatif terbaik yang saya temukan sejauh ini adalah menerima satuan pada nilainya. Misalnya mengizinkan 5 seconds atau 5s, dan memperlakukan 1 saja sebagai nilai yang tidak valid
  • Dalam code review, penggunaan int seperti itu sendiri saya tandai, lalu saya sarankan value class yang benar-benar membawa satuannya
    Misalnya Second(2) atau Millisecond(2000)
    Tentu saja ini bergantung pada fitur dan kebiasaan bahasa yang dipakai

• xmobar juga memakai satuan 0,1 detik di tempat yang mirip, tetapi lebih bermasalah. Itu adalah pengaturan yang menyatakan seberapa sering tiap bagian diperbarui
  Angka pada konfigurasi contohnya tampak terlalu kecil untuk mungkin berarti milidetik, jadi orang akan berasumsi wajar bahwa itu detik, dan akhirnya menjalankan perintah 10 kali lebih sering daripada yang dimaksud
  Saya sudah beberapa kali melihat lonjakan beban tak sengaja yang berasal dari masalah ini

• Ini tampak seperti desain yang cukup buruk
  Hanya saja poin nomor 1 berasal dari salah baca, dan “nilai sebelumnya” itu tidak pernah benar-benar ada di git

  1. Perubahan yang diam-diam menafsirkan ulang arti nilai konfigurasi lama, misalnya mengubah 1=true menjadi 1=penundaan konfirmasi 0.100ms, hampir selalu harus dihindari. Kalau nilai lama itu memang pernah ada, mungkin kita ingin menghapusnya, tetapi nama pengaturannya juga seharusnya ikut diganti
  2. Fakta bahwa argumen konfigurasi untuk help.autocorrect adalah waktu, dan diukur dalam satuan yang tidak standar bagi kebanyakan pengguna, ya memang buruk. Aktivasi seharusnya berupa boolean, dan waktu konfirmasi diatur lewat nilai pecahan
  • Untuk poin nomor 1, sepertinya ada salah paham soal urutan waktunya
    Perubahan itu terjadi pada 2008, saat code review patch awal yang ingin menambahkan opsi tersebut sebagai boolean, sebelum sempat di-commit ke pohon git utama
  • Kata “desain” memberi kesan ada rencana besar yang disengaja dalam konteks yang lebih luas
    Ini rasanya lebih seperti cabang samping yang tumbuh secara organik daripada sebuah desain

• Menurut saya ini contoh bagus dari feature creep
  Dalam penilaian paling baik, ini memasukkan kerumitan yang tidak perlu; dalam penilaian paling buruk, ini membuat orang yang bergantung padanya jadi kurang berhati-hati terhadap apa yang sedang mereka lakukan

  • git memang seperti itu. Di atas struktur data yang elegan, bertahun-tahun kemudian tertumpuk berbagai lapisan sampah tak perlu
  • Saya tidak paham kenapa orang ingin mengizinkan eksekusi otomatis
    Apa benar menekan panah atas lalu memperbaiki kesalahan itu begitu sulit? Menjalankan sesuatu yang “kurang lebih benar” secara otomatis adalah resep untuk melakukan hal yang tidak dimaksudkan

• Kesalahannya ada di sini. Seharusnya menambahkan pengaturan baru, bukan mendaur ulang pengaturan yang ada untuk makna lain
  help.autocorrect seharusnya dipisah menjadi hidup/mati, dan help.autocorrect.milliseconds untuk berapa lama menunggu
  Sistem lain juga punya kesalahan serupa. Misalnya, innodb_flush_log_at_trx_commit di MySQL bernilai 0 untuk nonaktif, 1 untuk aktif, lalu 2 ditambahkan belakangan dengan makna khusus

  • Masalah yang sebenarnya adalah bahasa konfigurasi tanpa tipe yang mencoba menebak apa arti 1
    Sekarang 1 dipertahankan sebagai boolean true, sementara bilangan bulat lain dijadikan satuan 0,1 detik, sehingga makin terjerumus
    Ini logika meragukan yang sama seperti no == false yang terkenal buruk di YAML
  • Tidak yakin paling cocok dipakai di mana, tetapi 0,1 detik juga bukan nilai yang sepenuhnya tidak masuk akal
    Secara catatan, waktu reaksi acak tercepat adalah sekitar 1,5 ds, dan kebetulan waktu reaksi rata-rata gamer juga sekitar itu, tetapi reaksi non-acak bisa jauh lebih cepat. Misalnya saat bereaksi mengikuti irama
    Jika memang ingin secepat itu, itu mungkin saja, dan kecepatan pemanggilannya juga seharusnya cukup stabil. Kira-kira di tingkat beberapa milidetik

• Setahun lalu aku menyalakan fitur autocorrect dan mengaturnya ke 3 detik, lalu merasakan dua hal

  1. Tidak membedakan tindakan berbahaya dan tindakan aman
  2. Mencemari riwayat shell dengan perintah yang salah ketik
     Setelah membaca tulisan ini, akhirnya ada dorongan yang cukup untuk mematikannya setelah setahun
  • Lebih baik bikin alias untuk typo yang sering terjadi
    Tentu saja itu juga “mencemari” riwayat shell
  • Soal poin 2, pencemar yang sebenarnya adalah diri sendiri
    Kalau menelusuri riwayat ke atas lalu tetap menjalankan ulang perintah salah terakhir hanya karena toh akan berjalan, hasilnya sama saja

• Satuan 0,1 detik benar-benar pilihan yang aneh
  Lebih masuk akal jika latensi ditentukan dalam milidetik atau detik, dan keduanya jauh lebih umum dipakai dalam komputasi

  • Sempat cukup bingung. Kukira deciseconds adalah satuan khusus git, semacam decision-seconds, yaitu “detik yang dibutuhkan untuk mengambil keputusan” xD
    Sebagai catatan, bahasa Inggris bukan bahasa ibuku, tetapi aku berasal dari wilayah beradab yang memakai sistem metrik
  • Cocok untuk waktu reaksi manusia, tetapi tetap satuan yang jarang dipakai
    Perbedaan antara 0 detik dan 1 detik terasa jelas saat menunggu sesuatu, tetapi perbedaan antara n milidetik dan n+1 milidetik terlalu halus untuk berguna secara praktis

• Waktu reaksi berbeda tergantung jenis rangsangan; pendengaran sedikit lebih cepat daripada penglihatan, dan sentuhan sedikit lebih cepat lagi, sekitar 90~180ms
  Jadi kalau git menamparmu alih-alih menampilkan pesan kesalahan, mungkin kamu nyaris masih sempat bereaksi

  • Agar alat penampar itu terasa pas, ia harus membangun momentum
    Apakah 10ms cukup untuk itu?

• Membaca tulisan ini membuatku teringat pada arkeologi perangkat lunak dan istilah “arkeolog programmer”
  Untuk konsep yang kedua, kita harus berterima kasih pada Vernor Vinge

  • Ini bagian yang benar-benar mengganggu. Para hacker membesar-besarkan seolah konsep “arkeologi perangkat lunak” diperkenalkan oleh buku itu, jadi aku sangat menantikan membaca A Fire Upon The Deep
    Ternyata konsep itu hanya disinggung sekilas di prolog, lalu tidak muncul lagi setelahnya. Dampak arkeologinya memang berkaitan dengan alur, tetapi “arkeolog perangkat lunak” bukan tokoh yang berarti dalam narasinya
    Rasanya seperti kena jebak
  • Aku sering bilang bahwa bahaya arkeologi perangkat lunak adalah pada akhirnya kita akan menemukan coprolite
  • Aku tidak bisa menghilangkan perasaan bahwa ini seperti sedang memanggilku “tua”