Formula One ड्राइवरों के लिए Git Autocorrect बहुत तेज़ क्यों है

 (blog.gitbutler.com)
1 पॉइंट द्वारा GN⁺ 2025-01-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Git का help.autocorrect=1 टाइपो वाले कमांड को ठीक करने के बाद सिर्फ 0.1 सेकंड रुकता है और फिर उसे चला देता है, इसलिए यूज़र के लिए उसे verify या cancel करना लगभग नामुमकिन है
  • यह behavior Git का default नहीं है; default setting में यह unknown command को चलाने के बजाय सिर्फ मिलते-जुलते commands दिखाकर बाहर निकल जाता है
  • 2008 की चर्चा में help.autocorrect को boolean के बजाय decisecond unit में wait time में बदला गया, इसलिए 1 को true नहीं बल्कि 0.1 सेकंड की देरी के रूप में समझा जाता है
  • अभी help.autocorrect 0, positive numbers, immediate, prompt, never को support करता है, और confirmation के बाद run कराना हो तो prompt ज़्यादा सुरक्षित विकल्प है
  • Git का command estimation modified Levenshtein distance पर आधारित है, और Scott Chacon ने 1 और boolean strings को अधिक स्वाभाविक तरीके से handle करने वाला patch प्रस्तावित किया है

git pushy के git push के रूप में चलने तक की कहानी

  • जब @dhh ने git pushy टाइप किया, Git ने इसे git push के रूप में अनुमानित किया और run करने से पहले सिर्फ 0.1 सेकंड इंतज़ार किया
  • 0.1 सेकंड इतना कम समय है कि यूज़र न कमांड ठीक से पढ़ सकता है, न तय कर सकता है कि यह सही है, और न ही cancel कर सकता है
  • यह behavior Git का default behavior नहीं है; यह तब दिखता है जब help.autocorrect setting enabled हो

Default behavior और help.autocorrect की शुरुआत

  • Git की default प्रतिक्रिया यह है कि वह unknown command को run नहीं करता, बल्कि string similarity के आधार पर possible commands दिखाकर exit कर जाता है
    • उदाहरण: git pushy में यह push को सबसे मिलते-जुलते command के रूप में दिखा सकता है
  • शुरुआत में Git unknown command पर सिर्फ इतना कहता था कि यह “Git command नहीं है”
  • 2008 में Johannes Schindelin ने एक छोटा patch प्रस्तावित किया जिसमें known commands को scan करके सबसे मिलते-जुलते command को खोजा जाता था, और अगर कोई एक ही नज़दीकी candidate हो तो उसे चलाया जाता था
  • Alex Riesen ने इसे help.autocorrect setting से control करने वाला patch दिया, और शुरुआत में यह setting boolean थी
    • Git config में boolean values में 1 को true माना जा सकता है
    • इसलिए मूल संदर्भ में help.autocorrect=1 auto-correct on करने वाली value जैसा लग सकता था

1 कैसे 0.1 सेकंड बन गया

  • Junio Hamano ने प्रस्ताव दिया कि help.autocorrect को simple boolean नहीं बल्कि run से पहले wait करने वाले decisecond की संख्या बनाया जाए
    • decisecond, 0.1 सेकंड की unit है
    • उद्देश्य यह था कि यूज़र को ^C दबाने का मौका मिल सके
  • बाद में स्वीकार किए गए patch में setting value को wait time में बदल दिया गया
  • नतीजतन help.autocorrect=1 का मतलब “feature on करो” नहीं, बल्कि “1 decisecond, यानी 0.1 सेकंड रुककर run करो” हो गया
  • decisecond को उचित time unit के रूप में क्यों चुना गया, इसका रिकॉर्ड चर्चा में नहीं मिलता

अभी उपलब्ध setting values

  • Git documentation के अनुसार help.autocorrect इन values को support करता है
    • 0: default value, जिसमें सिर्फ suggested commands दिखाए जाते हैं
    • positive number: बताए गए decisecond के बाद suggested command run होता है
    • immediate: suggested command तुरंत run होता है
    • prompt: suggestion दिखाकर पूछा जाता है कि run करना है या नहीं
    • never: suggested command न run होता है, न दिखाया जाता है
  • अगर आप confirmation के बाद run कराना चाहते हैं, तो prompt ज़्यादातर users के लिए अधिक practical है
  • setting example इस प्रकार है
git config --global help.autocorrect prompt
  • इसके बाद git pushy जैसे command पर push चलाने से पहले [y/N] के साथ confirmation पूछा जाएगा

Git मिलते-जुलते command कैसे चुनता है

  • Git अंधाधुंध command का अनुमान नहीं लगाता; एक सीमा के बाद वह मान लेता है कि input बहुत दूर है और कोई candidate नहीं देता
  • उदाहरण इस प्रकार हैं
    • git bass को rebase के काफ़ी नज़दीक मानकर run confirmation दिखाया जाता है
    • git bassa को अब rebase मानना मुश्किल समझा जाता है, इसलिए candidate run नहीं किया जाता
    • git dm में am और rm दोनों को similar command के रूप में दिखाया जाता है
    • git dma एकमात्र am से match होता है
  • यह logic modified Levenshtein distance algorithm पर आधारित है
    • यह गिनता है कि एक string को दूसरी string में बदलने के लिए कितनी character edits चाहिए
    • कुछ operations को दूसरे operations की तुलना में अधिक costly माना जाता है
  • Git में एक hardcoded cutoff है; अगर known command तक पहुँचने की cost बहुत ज़्यादा हो, तो यह मान लिया जाता है कि यूज़र ने command बहुत गलत टाइप किया है और फिर अनुमान नहीं लगाया जाता

1 की व्याख्या बदलने वाला patch

  • क्योंकि help.autocorrect=1 इंसानी नज़रिए से लगभग immediate जैसा ही है, Scott Chacon ने एक छोटा patch लिखा जिसमें 1 को 0.1 सेकंड की देरी के बजाय तुरंत run के रूप में समझा जाता है
  • Junio Hamano ने कहा कि सिर्फ "1" को special-case न किया जाए, बल्कि yes, no, true, off जैसी boolean string values को भी सही तरह से parse किया जाए
  • patch का दूसरा version इन्हीं boolean string values की handling को शामिल करने की दिशा में आगे बढ़ रहा है
  • अगर यह patch merge हो जाता है, तो आने वाले Git versions में help.autocorrect को लेकर भ्रम कम हो सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-01-20
Hacker News की रायें

  • 70 के दशक में Hal Finney, Mattel Intellivision के लिए BASIC interpreter को 2KB ROM में फिट कर रहे थे, जहाँ हर byte कीमती था
    syntax error दिखाने के लिए उन्होंने सभी error messages को घटाकर EH? कर दिया था, और यह बात आज भी मजेदार लगती है कि वे इस पर काफी गर्व करते थे

    • EH? पुराने जमाने के interactive fiction games के text parser response के तौर पर भी खूब फिट लगता
      थोड़ा संबंधित तौर पर, पुराने BASIC variants में PRINT statement को ? के रूप में लिखने की सुविधा भी थी, लेकिन लगता है उसका मकसद memory बचाने से ज्यादा REPL में typing time घटाना था
    • बहुत फिजूलखर्ची है। ed तो सभी errors के लिए सिर्फ एक ? इस्तेमाल करता है, इसलिए 3 गुना बचत होती है
    • interpreter response के रूप में Eh? का सबसे शुरुआती उदाहरण मैंने RAND के JOSS में देखा था
      [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
      memory करीब 5KB थी, लेकिन Intellivision की तुलना में मशीन का वजन लगभग 5,000 pounds था
    • काफी शानदार है। मुझे नहीं पता था कि Hal उस दौर में personal computer hacker थे, और Hal की बात सुनते ही मुझे हमेशा Bitcoin याद आता है
    • मैं Wordle से निकला game xordle चलाता हूं, जिसमें एक board पर दो Wordle puzzles होते हैं
      इसलिए अगर आप कोई word guess करें और उसके सभी 5 letters green हो जाएं, तब भी वह दोनों answers में से कोई नहीं हो सकता। ऐसा होने पर मैंने दाईं तरफ बस Huh? दिखाना रखा है, और लोगों को वह हिस्सा पसंद है

  • मूल कारण यह है कि configuration का नाम खराब रखा गया
    अगर मूल setting का नाम help.autocorrect_enabled जैसा boolean-सा रखा गया होता, तो integer value लेकर उसे 0.1 second units में interpret करने की मांग बेतुकी लगती। इसके बजाय help.autocorrect_accept_after_dsec जैसी अलग setting चाहिए होती, और dsec इतना अनजाना है कि जो भी इसे इस्तेमाल करता, उसे इसे lookup करना ही पड़ता
    code review में मैं हमेशा ऐसी चीज मांगता हूं। अगर ambiguity हो सकती है, तो variable name में unit होना चाहिए। जैसे int timeout को int timeout_msec होना चाहिए
    configuration names में यह 100 गुना ज्यादा जरूरी है। क्योंकि settings public interface का हिस्सा होती हैं, इसलिए उन्हें बाद में बदला नहीं जा सकता

    • मेरी भी यही सोच है। हालांकि जब यह type system में धकेला जाता है, तो मुझे अब भी दुविधा होती है
      C++ context में मोटा-मोटी guideline यह है कि void FooBar(std::chrono::milliseconds timeout); ठीक है। क्योंकि function signature है, इसलिए देखते समय type भी साथ दिखता है
      लेकिन variable में timeout ठीक नहीं है। 99% मामलों में असल use auto timeout = gl_timeout; या FooBar(timeout); जैसा दिखता है
      C++ में auto आम तौर पर इस्तेमाल होने से, जब जरूरी हो तब exact type track करना काफी झंझट हो जाता है
      C++ पर काम करते समय मैं IDE या language server वाले editor का इस्तेमाल करता हूं, लेकिन हर 5 second में mouse hover करके type check करने का समय नहीं होता
    • सही है, और इसमें ऐसी time unit 0.1 second unit (decisecond) इस्तेमाल करना, जिसे जिंदगी भर literally 0 बार लिखा है, स्थिति को और खराब करता है
      अगर message में “1ms बाद execute करता है” दिखता, तो तुरंत setting check कर लेता
    • फिर आप systemd जैसी स्थिति में पहुंच जाते हैं, जहां TimoutSec=60 भी लिख सकते हैं और TimeoutSec=1min भी
      मुझे लगता है कि बेहतर होता unit को नाम में न डालते। हालांकि उस अजीब case को छोड़ दें तो मैं पूरी तरह सहमत हूं
    • ऐसा करता तो हूं, लेकिन यह सोच हटाना मुश्किल है कि इसमें Hungarian notation की बू आती है
      अब तक मिला सबसे अच्छा alternative यह है कि value में unit लिया जाए। जैसे 5 seconds या 5s allow करें, और plain 1 को invalid value मानें
    • code review में ऐसे int use को ही flag करता हूं, और उसके बजाय unit ठीक से carry करने वाली value class recommend करता हूं
      जैसे Second(2) या Millisecond(2000)
      बेशक यह language की features और conventions पर निर्भर करता है

  • xmobar भी मिलती-जुलती, लेकिन ज्यादा problematic जगह पर 0.1 second unit इस्तेमाल करता है। यह वह setting है जिसमें declare किया जाता है कि हर section कितनी बार refresh होगा
    example config में numbers इतने छोटे हैं कि milliseconds तो हो ही नहीं सकते, इसलिए यह reasonable लगता है कि वे seconds होंगे, और नतीजा यह होता है कि command intended से 10 गुना ज्यादा बार चलती है
    मैंने इस issue से पैदा हुए accidental load spikes कई बार देखे हैं

  • यह काफी खराब design लगता है
    हालांकि point 1 article को गलत पढ़ने का नतीजा था, और “previous value” git में कभी मौजूद नहीं थी

    1. existing setting value को चुपचाप किसी और meaning में reinterpret करने वाला बदलाव, जैसे 1=true को 1=0.100ms confirmation delay में बदलना, लगभग हमेशा avoid करना चाहिए। अगर कोई existing value होती तो उसे हटाना चाहेंगे, लेकिन setting name भी बदलना सही है
    2. help.autocorrect का configuration argument time होना, और वह भी ऐसी unit में मापा जाना जो ज्यादातर users के लिए standard नहीं है, बस खराब है। enablement boolean से लें, और confirmation time को fractional value से adjust करने दें
    • point 1 पर लगता है आपने timeline गलत समझी है
      वह बदलाव 2008 में हुआ था, उस option को boolean के रूप में add करने वाले शुरुआती patch की code review के दौरान, और main git tree में commit होने से पहले
    • “design” कहने पर intentional, broad-context planning का खयाल आता है
      यह design से ज्यादा organically उगी हुई side branch जैसा है

  • मुझे यह feature creep (creeping featurism) का अच्छा उदाहरण लगता है
    अच्छे से अच्छा देखें तो यह unnecessary complexity लाता है, और बुरे case में इस पर निर्भर लोग जो कर रहे हैं उस पर कम ध्यान देने लगते हैं

    • git बिल्कुल ऐसा ही है। elegant data structure के ऊपर समय के साथ जमा हुई unnecessary garbage की कई परतें चढ़ी हुई हैं
    • समझ नहीं आता कि कोई automatic execution क्यों allow करना चाहेगा
      up arrow दबाकर mistake ठीक करना इतना मुश्किल है क्या? “लगभग सही” चीज को अपने-आप execute करना unintended काम करवाने की recipe है

  • गलती यहीं थी। पुराने config को किसी और मतलब में दोबारा इस्तेमाल करने के बजाय नई config जोड़नी चाहिए थी
    help.autocorrect को on/off के लिए, और help.autocorrect.milliseconds को कितनी देर इंतज़ार करना है, इसके लिए अलग रखना चाहिए था
    दूसरे systems में भी ऐसी ही गलतियां हैं। जैसे MySQL का innodb_flush_log_at_trx_commit: 0 का मतलब disabled, 1 का मतलब enabled, और 2 बाद में एक खास meaning के साथ जोड़ा गया

    • असली समस्या बिना type वाली config language है, जो यह guess करने की कोशिश करती है कि 1 का मतलब क्या है
      अब 1 को boolean true रखते हुए बाकी integers को 0.1 सेकंड की units बना दिया गया है, और बात और उलझती जा रही है
      यह YAML के कुख्यात no == false जैसी ही संदिग्ध logic है
    • यह सबसे बेहतर कहां काम आएगा, पता नहीं, लेकिन 0.1 सेकंड भी कोई बेतुकी value नहीं है
      रिकॉर्ड के हिसाब से सबसे तेज़ random reaction time करीब 1.5ds है, और संयोग से average gamer reaction time भी लगभग इतना ही होता है, लेकिन non-random reactions कहीं ज़्यादा तेज़ हो सकते हैं। जैसे beat के साथ react करना
      अगर आप इतना तेज़ जाना चाहते हैं, तो मुमकिन है, और call speed भी अपेक्षाकृत stable होनी चाहिए। मोटे तौर पर कुछ milliseconds के level पर

  • एक साल पहले मैंने autocorrect feature चालू करके उसे 3 सेकंड पर set किया था, और दो बातें महसूस हुईं

    1. यह dangerous actions और safe actions में फर्क नहीं करता
    2. गलत type किए गए command से shell history को गंदा कर देता है
      यह लेख पढ़ने के बाद, एक साल बाद इसे बंद करने की वजह मिल गई
    • बेहतर है कि जो typos बार-बार होते हैं उनके लिए alias बना लिया जाए
      हालांकि वह भी shell history को “गंदा” तो करता ही है
    • नंबर 2 के बारे में, असली गंदगी फैलाने वाले आप खुद हैं
      history में पीछे जाकर, सिर्फ इसलिए आखिरी गलत command को फिर से चलाना कि वह वैसे भी काम कर जाता है, तब भी यही बात है

  • 0.1 सेकंड की units वाकई अजीब choice है
    latency को milliseconds या seconds में specify करना बेहतर है, और computing में दोनों कहीं ज़्यादा आम हैं

    • मैं थोड़ी देर के लिए काफी confuse हो गया था। लगा deciseconds कोई git-specific unit है, जिसका मतलब decision-seconds है—जैसे “decision लेने के लिए चाहिए seconds” xD
      संदर्भ के लिए, English मेरी native language नहीं है, लेकिन मैं metric system इस्तेमाल करने वाले civilized इलाके से हूं
    • इंसानी reaction time के लिए ठीक है, मगर uncommon unit है
      0 सेकंड और 1 सेकंड का फर्क किसी चीज़ का इंतज़ार करते समय साफ़ तौर पर लंबा लगता है, लेकिन n milliseconds और n+1 milliseconds का फर्क practical use के लिए बहुत ही छोटा है

  • reaction time stimulus के type पर निर्भर करता है; auditory, visual से थोड़ा तेज़ होता है, और tactile उससे भी थोड़ा तेज़, करीब 90~180ms
    इसलिए अगर git error message दिखाने के बजाय एक थप्पड़ मार दे, तो शायद मुश्किल से react करने का time मिल जाए

    • उस थप्पड़ मारने वाले device को सच में hit जैसा feel कराने के लिए inertia पैदा करनी होगी
      क्या 10ms उसके लिए काफी होगा?

  • यह लेख पढ़कर software archaeology और “programmer archaeologist” शब्द याद आ गए
    बाद वाले concept के लिए Vernor Vinge को credit देना चाहिए

    • यही बात सच में खटकती है। hackers “software archaeology” concept को उस किताब द्वारा introduce किया गया बताकर इतना hype करते थे कि मैं 『A Fire Upon The Deep』 पढ़ने को लेकर बहुत excited था
      लेकिन वह concept prologue में बस हल्का-सा hint होता है, और उसके बाद बिल्कुल नहीं आता। archaeology का प्रभाव plot से जुड़ा है, लेकिन “software archaeologist” narrative में कोई meaningful character नहीं था
      लगा जैसे मुझे bait किया गया
    • कहा जाता है कि software archaeology का खतरा आखिरकार coprolite मिल जाने में है
    • यह feeling हट नहीं रही कि अभी मुझे “बूढ़ा” कहा जा रहा है