Git Autocorrect neden Formula 1 sürücüsü için bile fazla hızlı?

• Git'te help.autocorrect=1, yazım hatalı komutu düzelttikten sonra yalnızca 0,1 saniye bekleyip çalıştırır; bu da kullanıcının onaylaması ya da iptal etmesi için pratikte neredeyse anında yürütme anlamına gelir
• Bu davranış Git'in varsayılanı değildir; varsayılan ayarda bilinmeyen bir komut çalıştırılmaz, bunun yerine yalnızca benzer komutlar gösterilip çıkılır
• 2008'deki tartışmada help.autocorrect, boolean olmaktan çıkarılıp desisaniye cinsinden bekleme süresi haline getirildi; böylece 1, true yerine 0,1 saniyelik bekleme olarak yorumlanır oldu
• Şu anda help.autocorrect; 0, pozitif sayılar, immediate, prompt, never değerlerini destekliyor ve onaydan sonra çalıştırmak için prompt daha güvenli bir seçim
• Git'in komut tahmini, değiştirilmiş Levenshtein distance temellidir ve Scott Chacon, 1 ile boolean dizelerini daha doğal ele alan bir yama önerdi

---

git pushy, git push olarak nasıl çalıştırılıyor?

• @dhh git pushy yazdığında Git bunu git push olarak tahmin ediyor ve çalıştırmadan önce yalnızca 0,1 saniye bekliyor
• 0,1 saniye, kullanıcının komutu okuyup doğru olup olmadığına karar vermesi ve iptal etmesi için fazla kısa
• Bu davranış Git'in varsayılan davranışı değil; help.autocorrect ayarı açıkken ortaya çıkıyor

Varsayılan davranış ve help.autocorrectün doğuşu

• Git'in varsayılan tepkisi, bilinmeyen bir komutu çalıştırmamak; bunun yerine dize benzerliğine göre olası komutları gösterip çıkmaktır
  • Örneğin: git pushy, en benzer komutun push olduğunu gösterebilir
• Başlangıçta Git, bilinmeyen bir komuta yalnızca “Git komutu değil” diye yanıt veriyordu
• 2008'de Johannes Schindelin, bilinen komutları tarayıp en benzer olanı bulan ve yakın aday yalnızca bir taneyse onu çalıştıran küçük bir yama önerdi
• Alex Riesen bunu help.autocorrect ayarıyla kontrol eden bir yama sundu ve başlangıçta bu ayar boolean idi
  • Git ayarlarında boolean değerler 1 değerini true olarak yorumlayabilir
  • Bu yüzden ilk bağlamda help.autocorrect=1, otomatik düzeltmeyi açan bir değer gibi görünebilirdi

1 neden 0,1 saniye oldu?

• Junio Hamano, help.autocorrectün basit bir boolean değil, çalıştırmadan önce beklenecek desisaniye sayısı olmasını önerdi
  • Desisaniye, 0,1 saniyelik birimdir
  • Amaç, kullanıcıya ^C basma fırsatı vermekti
• Daha sonra kabul edilen yamada ayar değeri bekleme süresine dönüştürüldü
• Sonuç olarak help.autocorrect=1, “özelliği aç” değil, “1 desisaniye, yani 0,1 saniye bekleyip sonra çalıştır” anlamına gelmeye başladı
• Desisaniyenin neden uygun zaman birimi olarak seçildiği tartışma kayıtlarında yer almıyor

Bugün seçilebilen ayar değerleri

• Git belgelerine göre help.autocorrect şu değerleri destekliyor
  • 0: varsayılan; yalnızca önerilen komutları gösterir
  • pozitif sayılar: belirtilen desisaniye süresinden sonra önerilen komutu çalıştırır
  • immediate: önerilen komutu hemen çalıştırır
  • prompt: öneriyi gösterir ve çalıştırılıp çalıştırılmayacağını sorar
  • never: önerilen komutu ne çalıştırır ne de gösterir
• Onaydan sonra çalıştırmak istiyorsanız prompt, çoğu kullanıcı için daha mantıklı
• Ayar örneği şöyle:

git config --global help.autocorrect prompt

• Bundan sonra git pushy gibi bir komut girerseniz, push komutunun çalıştırılıp çalıştırılmayacağı [y/N] ile sorulur

Git benzer komutu nasıl seçiyor?

• Git komutları rastgele tahmin etmez; belli bir noktadan sonra girdinin fazla uzak olduğuna karar verip aday önermez
• Örnek davranışlar şöyle:
  • git bass, rebase komutuna yeterince yakın sayılır ve çalıştırma onayı gösterilir
  • git bassa, artık rebase olarak görülemeyecek kadar uzak kabul edilir ve aday çalıştırılmaz
  • git dm, benzer komutlar olarak hem am hem rm gösterir
  • git dma, yalnızca am ile eşleşir
• Bu mantık, değiştirilmiş Levenshtein distance algoritmasına dayanır
  • Bir diziyi diğerine dönüştürmek için gereken karakter düzenleme maliyetini hesaplar
  • Bazı işlemler diğerlerinden daha pahalı kabul edilir
• Git'te sabit kodlanmış bir cutoff vardır; bilinen bir komuta maliyet fazla yüksekse, kullanıcının çok farklı bir şey yazdığı varsayılır ve tahmin yapılmaz

1 yorumunu değiştirmeye çalışan yama

• help.autocorrect=1, insan açısından pratikte immediate ile aynı olduğundan Scott Chacon, 1 değerini 0,1 saniyelik bekleme değil hemen çalıştırma olarak yorumlayan küçük bir yama yazdı
• Junio Hamano, yalnızca "1" için özel işlem yapılmamasını; yes, no, true, off gibi boolean dize değerlerinin de doğru yorumlanmasını istedi
• Yamanın ikinci sürümü, bu boolean dize işleme desteğini de içerecek şekilde ilerliyor
• Yama kabul edilirse, gelecekteki Git sürümlerinde help.autocorrect etrafındaki kafa karışıklığı azalabilir

[GN⁺]

Hacker News yorumları

• 70'lerde Hal Finney, Mattel Intellivision için BASIC yorumlayıcısını 2 KB ROM'a sığdırmaya çalışıyordu; her bayt değerliydi.
  Sözdizimi hatalarını göstermek için tüm hata mesajlarını EH? olarak kısaltmıştı; bununla epey gurur duymuş olması hâlâ komiğime gidiyor.

  • EH?, eski tarz interaktif kurgu oyunlarındaki metin ayrıştırıcı yanıtı olarak da gayet yakışırdı.
    Biraz bağlantılı olarak, eski BASIC türevlerinden bazılarında PRINT ifadesi ? ile yazılabiliyordu; bunun bellek tasarrufundan çok REPL'de yazma süresini azaltma amacı taşıdığını düşünüyorum.
  • Epey savurgan. ed tüm hatalar için tek bir ? kullanıyor, yani 3 kat tasarruf sağlıyor.
  • Yorumlayıcı yanıtı olarak Eh? kullanımının gördüğüm en eski örneği RAND'in JOSS sistemindeydi.
    [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
    Belleği yaklaşık 5 KB'tı ama Intellivision ile karşılaştırınca makinenin ağırlığı yaklaşık 5.000 pounddu.
  • Oldukça güzel. Hal'in o dönemlerde kişisel bilgisayar hacker'ı olduğunu bilmiyordum; Hal denince aklıma hep Bitcoin geliyor.
  • Wordle türevi bir oyun olan xordle'ı işletiyorum; tek tahtada iki Wordle bulmacası var.
    Bu yüzden bir kelime tahmin edip 5 harfin tamamı yeşil olsa bile iki cevaptan hiçbiri olmayabiliyor. Böyle olduğunda sağ tarafta sadece Huh? gösteriyorum; insanlar o kısmı seviyor.

• Temel neden, ayar adının kötü verilmiş olması.
  İlk ayar help.autocorrect_enabled gibi boolean izlenimi veren bir adla anılsaydı, tamsayı değer alıp bunu 0,1 saniyelik birimler olarak yorumlama isteği anlamsız olurdu. Bunun yerine help.autocorrect_accept_after_dsec gibi başka bir ayar gerekirdi; dsec de o kadar alışılmadık ki kullanan biri mecburen araştırırdı.
  Kod incelemelerinde bunu hep isterim. Belirsizlik olabiliyorsa değişken adında birim yer almalı. Örneğin int timeout, int timeout_msec olmalı.
  Ayar adlarında bu 100 kat daha önemli. Çünkü ayarlar kamusal arayüzün bir parçasıdır ve sonradan değiştirilemez.

  • Aynı fikirdeyim. Yalnız bu iş tip sistemine itildiğinde hâlâ kararsız kalıyorum.
    C++ bağlamında kabaca ölçütüm şu: void FooBar(std::chrono::milliseconds timeout); kabul edilebilir. Çünkü bu bir fonksiyon imzası; bakarken tipi de birlikte görürsünüz.
    Ama değişkenlerde timeout kabul edilebilir değil. Vakaların %99'unda gerçek kullanım auto timeout = gl_timeout; veya FooBar(timeout); gibi görünür.
    C++'ta auto yaygın kullanıldığı için, önemli olduğunda tam tipi izlemek epey zahmetli hâle geliyor.
    C++ ile çalışırken IDE ya da language server bağlı bir editör kullanıyorum ama her 5 saniyede bir fareyi üzerine getirip tipi kontrol edecek vaktim yok.
  • Evet; buna bir de hayatı boyunca kelimenin tam anlamıyla sıfır kez kullanmış olduğum bir zaman birimi olan 0,1 saniyelik birimi (decisecond) kullanmaları durumu daha da kötüleştiriyor.
    “1 ms sonra çalıştırılıyor” mesajını görseydim ayarı hemen kontrol ederdim.
  • Böyle böyle systemd'deki gibi hem TimoutSec=60 hem de TimeoutSec=1min yazılabilen bir duruma geliyorsunuz.
    Bence birimi ada koymamak daha iyi olurdu. Yine de o özel tuhaf durum dışında tamamen katılıyorum.
  • Ben de öyle yapıyorum ama bunun Macar notasyonu kokusu verdiği düşüncesinden kurtulmak zor.
    Şimdiye kadar bulduğum en iyi alternatif, değerin birimle birlikte alınması. Örneğin 5 seconds veya 5s kabul edilip, tek başına 1 geçersiz değer sayılabilir.
  • Kod incelemelerinde böyle int kullanımının kendisini işaretleyip, bunun yerine birimi doğru taşıyan bir değer sınıfı öneriyorum.
    Örneğin Second(2) veya Millisecond(2000) gibi.
    Elbette bu, dilin özelliklerine ve alışkanlıklarına göre değişir.

• xmobar da benzer ama daha sorunlu bir yerde 0,1 saniyelik birimler kullanıyor. Her bölümün ne sıklıkla yenileneceğini belirten ayar bu.
  Örnek yapılandırmadaki sayılar milisaniye olamayacak kadar küçük görünüyor; bu yüzden makul olarak saniye varsaymanıza yol açıyor ve sonuçta komutlar amaçlanandan 10 kat daha sık çalıştırılıyor.
  Bu sorundan kaynaklanan tesadüfi yük sıçramalarını birkaç kez gördüm.

• Epey kötü bir tasarım gibi görünüyor.
  Ancak 1. madde yazıyı yanlış okumanın sonucuydu; “önceki değer” git'te hiç var olmamıştı.

  1. Mevcut bir ayar değerini sessizce başka bir anlama gelecek şekilde yeniden yorumlayan değişikliklerden, örneğin 1=true değerini 1=0.100ms onay gecikmesi olarak değiştirmekten neredeyse her zaman kaçınmak gerekir. Mevcut bir değer olsaydı silmek isteyebilirdiniz, ama ayar adını da değiştirmek doğru olurdu.
  2. help.autocorrect ayar argümanının zaman olması ve çoğu kullanıcı için standart olmayan bir birimle ölçülmesi düpedüz kötü. Etkinleştirme boolean olarak alınmalı, onay süresi de ondalıklı bir değerle ayarlanabilmeli.
  • 1. madde konusunda zaman sırasını yanlış anlamış gibisiniz.
       Bu değişiklik 2008'de, ilgili seçeneği boolean olarak eklemeye yönelik ilk yamanın kod incelemesi sırasında yapıldı ve ana git ağacına commit edilmeden önceydi.
  • “Tasarım” deyince akla bilinçli, geniş kapsamlı bir plan geliyor.
    Bu, tasarımdan çok organik biçimde büyümüş bir yan dal gibi.

• Bence bu, özellik şişmesi (creeping featurism) için iyi bir örnek.
  İyi tarafından bakılsa bile gereksiz karmaşıklık getiriyor; kötü tarafından bakınca da buna güvenen insanların ne yaptıklarına daha az dikkat etmesine yol açıyor.

  • git tam olarak böyle. Zarif bir veri yapısının üstü, yıllar içinde birikmiş gereksiz çöp katmanlarıyla kaplanmış durumda.
  • Neden otomatik çalıştırmaya izin vermek istediklerini anlamıyorum.
    Yukarı ok tuşuna basıp hatayı düzeltmek bu kadar mı zor? “Aşağı yukarı doğru” olan bir şeyi otomatik çalıştırmak, istemediğiniz şeyleri yaptırmanın tarifidir.

• Hata buradaydı. Mevcut ayarı başka bir anlam için yeniden kullanmak yerine yeni bir ayar eklenmeliydi
  help.autocorrect açma/kapama, help.autocorrect.milliseconds ise ne kadar bekleneceği olarak ayrılmalıydı
  Başka sistemlerde de benzer hatalar var. Örneğin MySQL’de innodb_flush_log_at_trx_commit 0 ise devre dışı, 1 ise etkin; 2 ise daha sonra özel bir anlamla eklendi

  • Asıl sorun, 1in ne anlama geldiğini tahmin etmeye çalışan tipsiz yapılandırma dili
    Şimdi 1 boolean doğru olarak bırakılırken diğer tamsayılar 0,1 saniye birimi yapılıyor ve daha da derine batılıyor
    YAML’in kötü şöhretli no == false durumu gibi şüpheli bir mantık
  • En iyi nerede işe yarar bilmiyorum ama 0,1 saniye de tamamen anlamsız bir değer değil
    Kayıtlardaki en hızlı rastgele tepki süresi yaklaşık 1,5 ds ve tesadüfen ortalama oyuncu tepki süresi de o civarda; ancak rastgele olmayan tepkiler çok daha hızlı olabilir. Örneğin ritme uyarak tepki vermek böyledir
    O kadar hızlı gitmek istiyorsanız mümkün ve çağrı hızı da nispeten istikrarlı olmalı. Kabaca birkaç milisaniye düzeyinde olur

• Bir yıl önce otomatik düzeltmeyi açıp 3 saniyeye ayarlamıştım; iki şey fark ettim

  1. Tehlikeli işlemlerle güvenli işlemler arasında ayrım yapmıyor
  2. Yanlış yazılmış komutla shell geçmişini kirletiyor
     Bu yazıyı okuyunca, bir yıl sonra kapatmam için yeterli gerekçeyi bulmuş oldum
  • Sık yapılan yazım hataları için alias oluşturmak daha iyi
    Elbette shell geçmişini yine “kirletiyor”
  • 2. maddeye gelince, gerçek kirleten kişi aslında sizsiniz
       Geçmişte geriye gidip, nasıl olsa çalışıyor diye sondaki yanlış komutu aynen tekrar kullansanız da durum aynı

• 0,1 saniye birimi gerçekten tuhaf bir seçim
  Gecikmeyi milisaniye ya da saniye cinsinden belirtmek daha iyi; ikisi de bilişimde çok daha yaygın kullanılıyor

  • Bir an epey kafam karıştı. decisecondsın git’e özgü bir birim olup “karar vermek için gereken saniyeler” anlamında decision-seconds demek olduğunu sandım xD
    Bu arada İngilizce ana dilim değil ama metrik sistemi kullanan medeni bir bölgeden geliyorum
  • İnsan tepki süresi için fena değil ama yaygın olmayan bir birim
    0 saniye ile 1 saniye arasındaki fark, bir şeyi beklerken belirgin biçimde uzundur; ama n milisaniye ile n+1 milisaniye arasındaki fark kullanışlı olamayacak kadar incedir

• Tepki süresi uyaran türüne göre değişir; işitsel uyaran görselden biraz daha hızlıdır, dokunsal uyaran ise ondan da biraz hızlı olup yaklaşık 90~180 ms düzeyindedir
  Bu yüzden git hata mesajı yerine size bir yumruk atsaydı, belki zar zor tepki verecek zamanınız olurdu

  • O vurma cihazının gerçekten vuruyormuş hissi vermesi için atalet yaratması gerekir
    10 ms bunun için yeterli olur mu?

• Bu yazıyı okuyunca aklıma yazılım arkeolojisi ve “programcı arkeolog” ifadeleri geldi
  İkinci kavram için Vernor Vinge’e teşekkür etmek gerek

  • Bu gerçekten sinir bozucu bir nokta. Hacker’lar “yazılım arkeolojisi” kavramını o kitabın ortaya attığını övdüğü için 『A Fire Upon The Deep』 okumayı çok bekliyordum
    Ama kavram prologda kısaca ima ediliyor ve sonrasında hiç yok. Arkeolojinin etkisi olay örgüsüyle ilgili ama “yazılım arkeoloğu” anlatıda anlamlı bir kişi değildi
    Kandırılmış gibi hissettim
  • Yazılım arkeolojisinin tehlikesi, sonunda koprolit keşfetmenizdir derler
  • Şu an bana “yaşlı” deniyormuş gibi hissetmekten kendimi alamıyorum