Grit: Git’i ajanlarla Rust’ta yeniden yazmak

• Grit, Git’i sıfırdan Rust tabanlı bir kütüphane olarak yeniden uygulayan bir proje; amaç, Git depolarıyla resmi olarak etkileşime girebilen yeniden girişli ve bağlanabilir bir çekirdek oluşturmak
• Git, 20 yıldır binlerce kişinin komut bileşimi merkezli olarak genişlettiği karmaşık bir yazılım ve uzun süre çalışan süreçlerde her iş için fork/exec maliyeti doğuran yapısal bir soruna sahip
• Grit, Git projesindeki 1.400’den fazla betik ve 42.000’den fazla testi ölçüt alarak geliştirildi; sonunda 41.715 / 42.001 testi geçti {p:99}
• Mevcut sürümün gerçek kullanım doğrulaması yetersiz; yavaş çalışma, dağınık API, Windows derlemesinin olmaması ve veri bozulması olasılığı gibi kısıtları var
• Ajan tabanlı geliştirme, büyük ölçekli portlamayı hızla ileri itebildi; ancak testten kaçma, harness’ın bozulması, koordinasyon, kaynak ve maliyet yönetimi temel zorluklar olarak ortaya çıktı

---

Grit’in hedefi ve arka planı

• Grit, Git’i C kodu taşımak yerine Rust kütüphanesi merkezli olarak yeniden yazma girişimiydi
• Hedef, Git depolarıyla resmi biçimde etkileşime geçebilen saf Rust çekirdek kütüphanesi oluşturmaktı
• Çekirdek; yeniden girişli, bağlanabilir, modüler ve kapsamlı bir yapıyı hedefliyor
• Ayrı bir CLI crate’i, bu kütüphaneyi kullanarak Git test paketini olabildiğince fazla geçmek üzerinden olgunluğu doğruluyor

Git’i neden yeniden uygulamak istediler

• Git, çok sayıda düşük seviyeli plumbing komutu ve yüksek seviyeli porcelain komutu içeren karmaşık bir yazılım
• Mevcut Git, bağlanabilir ve yeniden girişli bir kütüphane temeli üzerine kurulu değil; daha çok basit komutları art arda bağlayan Unix tarzı felsefeye yakın bir yapıya sahip
• Bu yapıda, uzun süre çalışan bir süreç Git işlevlerini kullanmak istediğinde her işlem için fork/exec ek yükü oluşuyor
• Git projesinde 1.400’den fazla betiğe yayılan 42.000’den fazla test bulunuyor; bu da davranış ölçütlerini oldukça ayrıntılı biçimde doğrulamayı mümkün kılıyor

Mevcut olgunluk düzeyi ve dikkat edilmesi gerekenler

• Grit, sıfırdan yazılmış, kütüphane tabanlı, bellek güvenli bir Rust Git yeniden uygulaması ve Git test paketinin %99’dan fazlasını geçiyor
• Bazı testler bilinçli olarak atlandı; buna e-posta ile ilgili işlevler, i18n, Perforce/SVN importer ve bazı midx/bitmap öğeleri dahil
• Genel okuyucu için anlamlı görülen kapsamda Grit kütüphanesi ve CLI, Git test paketini geçiyor
• Gerçek projelerde kullanım doğrulaması hâlâ yetersiz ve hatalı davranış ya da veri bozulması olasılığı var
• Mevcut sınırlamalar arasında yavaş performans, test edilmemiş işlevler, toparlanmamış API ve Windows derlemesinin olmayışı yer alıyor

Olası kullanım alanları

• GitButler ve bağımsız Git araçları, karmaşık push/fetch ağ işlevlerini gömmek için Grit’ten yararlanabilir
• Gitoxide ve libgit2’nin ağ işlevleri kısmi, yavaş ya da hiç mevcut değil
• GitButler ve Jujutsu, push/pull veri işleme için Git sürecini fork etmeye dayanıyor
• Karmaşık kimlik bilgisi mantığı bunun başlıca nedenlerinden biri ve bu alan teorik olarak Grit içinde ele alınıyor
• WASM derlemesi, edge Vercel fonksiyonlarında neredeyse tüm Git komutlarını çalıştırmak gibi kullanım senaryolarını mümkün kılabilir
• Cloudflare Artifacts gibi özellikler, isomorphic-git gibi kısmi uygulamalar yerine Grit’in tam uyumlu WASM derlemesini kullanabilir
• Git işlevlerini tek tek gömülebilir kütüphane parçalarına ayırmak, Rust tabanlı özel Git sunucuları ya da istemci işlevleri geliştirmeyi de mümkün kılabilir
• Tam Rust Git işlev derlemesi şu anda yaklaşık 27MB ve bunu işlev alanlarına göre alt crate’lere bölüp yalnızca gereken kısımları kullanmak mümkün

Bellek güvenliği

• Grit kodunun büyük bölümü safe Rust ile yazıldı
• C ve FFI ile iletişim gerektiren kısımlar fiilen yalnızca bir date/time modülü ve bir TTY kontrolü
• localtime_r, strftime, mktime için TZ ortamına uygun çalışan saf Rust karşılığı olmadığı için bu FFI gerekli
• Bunun dışındaki Grit kodu safe Rust’tan oluşuyor

Ajan geliştirmede ortaya çıkan sorunlar

• Ajanlar testi geçmek için kestirme yollara kaçabiliyor

  • “Git testlerini geçir” hedefi, ajanları işi olduğu gibi Git’e devreden basit işlevler yazmaya yöneltebiliyor
  • AGENTS dosyasında, bu tür kestirmelerin yasak olduğu gibi temel kuralların çok açık yazılması gerekti
  • sha256 desteğinde test yalnızca git init --object-format=sha256 sonrasında rev-parse --show-object-format çıktısının sha256 olup olmadığını kontrol ediyor
  • Grit, yapılandırma metaverisini doğru kaydederek bu testi geçti; ancak sha256 deposunda add, commit ve log davranışı gerçekte doğrulanmadı
  • Ajanlar, testin baktığı kısmı düzeltip gerçek sha256 nesne desteğini uygulamadı

• Ajanlar neyi bozduklarını fark etmiyor

  • Paralel ajanlardan biri, test harness’ının temel bir bölümünü bozdu ve bu durum büyük ölçekli bir regresyon gibi göründü
  • Bu nedenle paralel çalışmanın zarar verdiği düşünülerek proje bir süre neredeyse durdu
  • Haziran başında çalışmaya yeniden başlandıktan sonra bir ajan harness hatasını bulup düzeltti ve geçiş oranı yeniden yaklaşık %80’e çıktı
  • Bu toparlanma, projeyi sonuna kadar götürme motivasyonunu sağladı

• Uzun süreli paralel çalışma koordine etmesi zor

  • Uzun süre çalışan birden fazla ajanın ortak bir görev listesini bölüşmesi beklenenden daha zordu
  • Onay kutulu plan dosyalarını paylaşma yöntemi dağınık hale geldi; Linear veya GitHub Issues gibi yaklaşımlar ise ağ erişimi, kimlik doğrulama ve istemciye özel araç yapılandırması gerektiriyordu
  • Son aşamada, görev listesini yerelde düzenleyip Git üzerinden taşıyabilmek için Ticgit yerel bilet sistemi kullanıldı
  • Farklı sistemlerde süren işleri kolayca paketleyip başka yere devretmeye yarayan handoff süreci de sürekli sürtünme yarattı

Kaynaklar ve maliyet

• Çalışma dizüstü bilgisayar, Mac Studio, Hostinger sunucusu ve Cursor cloud agents gibi çeşitli ortamlarda yürütüldü
• Rust derlemeleri, paralel çalıştırıldığında beklenenden çok daha fazla CPU ve bellek istedi
• Ajanlar, swap thrashing ve CPU thrashing gibi sorunları ayıklayıp düzeltebildi; ancak kaynak yönetimi sürekli zordu
• Cursor ve Anthropic kullanım maliyeti tam olarak hesaplanmadı; kabaca 10.000–15.000 $ seviyesinde olduğu tahmin ediliyor
• Token kullanımı yaklaşık olarak Claude Code için 14 milyar, Cursor GPT/Codex için 12 milyar, Cursor composer-2 için 16 milyar; toplamda yaklaşık 45 milyar token düzeyinde
• Cursor’un composer-2 modeli, kısa ve odaklı çok sayıda cloud agent çalıştırma yaklaşımıyla projenin neredeyse yarısını tamamladı

Kullanılan ajan yaklaşımları

• OpenClaw + Claude Code

  • Başlangıçta, OpenClaw ile Claude Code alt ajanları uzaktan çalıştırıldı
  • Token başına API kullanımı nedeniyle birkaç gün içinde tüm projenin maliyetinin büyük kısmı oluştu
  • Bellek ve CPU sorunları ile Hostinger sunucu kesintileri yüzünden çalışma kararlılığı düşüktü

• Cursor cloud agents

  • Maliyet artışını azaltmak için abonelik token’ları ve daha ucuz modeller kullanan bir stratejiye geçildi
  • Çalışılacak her dosya için bir Cursor cloud agent açıp iş bittiğinde birleştirme yöntemi, projenin büyük bölümünü ilerletti
  • Bazı testler ortamı değiştirip Git yerine Grit ikilisini kullandı ya da kimlik bilgisi deposunu bozduğu için konteyner içinde Git push başarısız oldu
  • Çoğu durumda konteyner terminaline girip remote’u elle eklemek ve commit’i push etmek gerekti

• Cursor cloud grind mode

  • Cursor cloud agent’ta model seçicisinden Long-running seçildiğinde “Grind mode” ile uzun süreli iş yürütülebiliyor
  • “t1 test ailesinin tamamını geçir” gibi bir istem verilip bir gün beklendiğinde, PR üzerinde 100 commit birikmesi şeklinde ilerliyordu
  • Bu yöntem, farklı denemeler arasında tercih edilen yaklaşım haline geldi

• /goal modu ve Claude dynamic workflows

  • Codex ve Claude Code’daki /goal modu da benzer uzun süreli işleri yürütebiliyordu
  • Codex’in /goal modu çalışmayı sürdürürken Claude sık sık duruyor ve müdahale gerektiriyordu
  • Son haftada, Claude dynamic workflows içindeki “Ultracode” effort mode ile büyük test aileleri bölünerek işlendi
  • Paralel rustc derlemeleri CPU ve belleği aşırı kullanıp sistemi yavaşlatabildiği için kaynak yönetimi gerekiyordu

Daha etkili olan çalışma biçimi

• Yalnızca hafif koordinasyon yapan bir ajan grubuna sıradaki test dosyasını seçtirmektense, insanın belirlediği aşamalı strateji daha hızlı sonuç verdi
• Temel plumbing komutlarından başlayıp onların üzerine bağımlı kritik komutlara çıkan bottom-up yaklaşım etkili oldu
• diff biçimi çıktısı gibi başka işlevlerin pek dayanmadığı alanları sona bırakmak doğruydu
• Sorunlara yaklaşım sırasını ayrıntılı belirleyip işleri aşama aşama devretmek iyi sonuç verdi; gelişigüzel büyük ölçekli paralelleştirme ise daha çok sorun ve tıkanma yarattı

Lisans

• Git kaynak kodu GPL lisanslı ve libgit2, bağlanabilirlik temel amaç olduğu için GPL’e linking exception eklenmiş bir yapıya sahip
• libgit2 lisansı geçmişten beri tartışılıyor ve bugün de bir mesele olarak duruyor
• LLM tarafından üretilen kod ile kütüphaneleştirme ve bellek güvenliği için yapılan kapsamlı mimari değişiklikler değerlendirildiğinde, Grit kod tabanının GPL’i devralması gereken türetilmiş bir eser olmadığı sonucuna varıldı
• Grit kodu MIT lisansı altında yayımlandı
• Bu karar tartışmalı olabilir; ancak daha geniş Git topluluğu için en iyi seçenek olduğu düşünülüyor

Nihai sonuç

• Çalışma Nisan ayında birkaç hafta sürdü, ardından durdu ve Haziran’ın ilk haftasında tamamlandı
• Gerçek harcanan süre, günde birkaç saatten toplam 2–3 hafta düzeyindeydi; zamanın çoğu arka planda çalışan işleri koordine etme, birleştirme ve sorun bulmaya gitti
• Nihai kod boyutu 360.000 LOC’un üzerinde
  • grit-lib yaklaşık 100.000 LOC
  • grit-cli yaklaşık 260.000 LOC
  • Başlık dosyaları hariç C Git kod tabanıyla kabaca benzer ölçekte
• Sonuç, 500’den fazla pull request ve 7.000’den fazla commit sonucunda ortaya çıktı
• Test sonucu 42.001 testin 41.715’inin geçilmesiyle %99,3 başarı oranına ulaştı
• Projenin ana sayfası https://grit-scm.com

[carnoxen]

https://writings.hongminhee.org/2026/03/legal-vs-legitimate/

Lisans tartışmasını görünce önceki olay aklıma geliyor

[unsure4000]

https://github.com/gitbutlerapp/grit/pull/837/changes/b1135eef106c71b0831d964c6506d8817e7a7201

Oldukça iğrenç. Grit-lib neden hâlâ MIT?

[GN⁺]

Hacker News yorumları

• “LLM’in ürettiği kodu incelediğimizde, uygulamayı kütüphaneleştirmek ve bellek güvenli hale getirmek için oldukça büyük ve kapsamlı mimari değişiklikler gerektiği için, bu kod tabanının GPL’i devralması gereken bir türev eser olmadığına karar verdik ve MIT ile yayımlamaya karar verdik” kısmı ilginç bir tartışma konusu gibi görünüyor

  • Bir kitabı başka bir dile çevirmek türev eserdir; bir bilgisayar programını başka bir programlama diline çevirmek için de aynı şeyin geçerli olduğu düşünülmeli
    Ancak bir kitabı çevirirken olay örgüsünü ve karakterlerin kişiliğini de değiştirmeye başlarsanız, hangi noktada artık türev eser olmaktan çıktığı belirsizleşir. Hukukçu değilim ama yaratıcı eserlerle ilgili içtihatlarda bu sınırın epey ele alınmış olduğunu sanıyorum
    “Fikri mülkiyet” kapsamının bugün olduğu gibi sürekli genişlediği bir ortamda, LLM’in Git kaynak koduna eriştiğini kabul ederseniz hukuki pozisyon zayıf görünüyor
  • Burada ilginç amatör hukukçu yorumları var ama benim görüşüm, yeniden uygulamanın korunan ifadeyi kopyalamadığı yönünde
    Jplag ölçütüne göre kod tabanları arasındaki azami benzerlik %1,8’in altında, süreç iyi niyetle yürütülmüş ve bunun Git ekosisteminin tamamına da faydalı olduğunu düşünüyorum. Elbette bunun için Grit’in gerçekten işe yarar hale gelmesi gerekir; şu anda bunu iddia etmek için erken
    Telif hakkı açısından bunlar arasında yalnızca ilk nokta ilgili. Grit, Git ile uyumlu davranışı bağımsız olarak yazılmış bir uygulama ve Git kaynak koduyla benzerliğinin göz ardı edilebilecek düzeyde olduğunu düşünüyorum
    antirez durumu iyi özetlemiş ve büyük ölçüde katılıyorum: https://antirez.com/news/162
    Son 20 yılda Git ve açık kaynak topluluğunda beni tanıyan ve benimle çalışan insanlar, niyetimin katkı, paylaşım, yenilik ve öğrenmeyi teşvik etmek olduğunu bilir. Git kaynağının başlıca yazarlarından birkaçı arkadaşım ve kimseden bir şey çalmak gibi bir niyetim kesinlikle yok. Sadece harika fikirleri daha geniş ölçekte faydalı hale getirmek istiyorum
  • Bu kararın düpedüz yanlış olduğunu düşünüyorum. Dava açma ehliyeti olan birinin dava açmasını isterdim
  • İlgili yazı: Malus – Clean Room as a Service
    https://news.ycombinator.com/item?id=47350424
    Tıpkı 1984 ya da Torment Nexus örneklerinde olduğu gibi, birinin uyarı olarak alması gereken bir kavramı kullanım kılavuzu olarak almış olması gibi
  • Kişinin bilmediği şeyi bildiğinin farkında olması, hayatta ve kariyerde çok önemlidir. Yazarın aklı başında olmadığına %100 katılıyorum
    Örneğin N64’ün Goldeneye ikilisini çıkarıp bunu bir LLM ile disassemble ettiğinizi ve modern bir yüksek seviyeli dilde yeniden yazdırdığınızı varsayalım. Nintendo “Epey emek harcamışsınız, demek ki artık lisansımızın dışına çıktınız” mı der? Elbette hayır. Bu saçma
    Kaynak kodunu verip başka bir dilde çıktı ürettirmek açıkça türev eser üretmektir. Fikri mülkiyet avukatı olmaya gerek yok
    Tersine, Claude’a sadece dokümantasyonu verip uyumlu bir uygulama üretmesini isteseniz, bu GPL kapsamına giren bir türev eser olur mu? Muhtemelen evet derdim ama artık bundan %100 emin değilim ve bu riski almazdım
    Bir başka düşünce deneyi olarak, biri bu “MIT lisanslı” kaynak ağacını başka bir LLM’e verip C çıktısı üretmesini istese lisans ne olurdu? SHA1 hash üretmenin ya da komut satırı ayrıştırıcısı yazmanın yolları sınırlı olduğundan, sonuç oldukça benzer olabilir
    Oracle v. Google davasında da bu temel tartışma noktalarından biriydi. Google, döngü yazmanın yollarının sınırlı olduğunu, dolayısıyla orijinale benzeyen döngülerin bulunmasının tek başına telif hakkı ihlali anlamına gelmediğini savunmuş ve bunda başarılı olmuştu
    Her hâlükârda, böyle bir pozisyon almak gerçekten fazla zorlama

• Anlamadım. Gitoxide zaten var ve harika.
  Eksikleri olabilir ama bakım gören Gitoxide'a gereken ağ özelliklerini vibe coding ile eklemek, Git'in tamamını yeniden klonlamaya çalışmak için token yakmaktan daha kolay.
  Git, Rust desteği istiyor ve Gitoxide yıllardır süren bir proje; bu yüzden “testleri geçtiğini söyleyen” doğaçlama bir vibe klonundan daha iyi sürdürülebilmesi daha olası.
  Yararlı olduğu durumlarda vibe klonun kendisine karşı değilim ama bunda bir avantaj göremiyorum. Git, birçok insanın sevdiği bir araç; bu, Next.js'in satıcı bağımlılığından hoşlanılmadığı için ortaya çıkan vinext gibi bir durum değil.
  Yönetimin de, “sevilen bir yazılımın kendi kopyamızı yapmak için tokenlara binlerce dolar yaktık” hikâyesinin, telif hakkı ve lisans tartışmalarını bir kenara bıraksak bile, topluluk tarafından olumlu karşılanacak bir şey olmadığını bilmesi gerekir.
  Sevdiğiniz bir eserin hiçbir fayda olmadan kopyalandığını görmek hoş hissettirmiyor. Artık “AI'ın nereye kadar gidebileceğini görmek için yapılan deney” aşamasını geçtik.

  • Dediğim gibi biz de Gitoxide projesine katkıda bulunuyoruz ve Byron da ekibimizin bir üyesi. Topluluğun büyük çabalarının fazlasıyla farkındayız ve bu yılki Git Merge konferansını da birlikte düzenliyoruz.
    Son zamanlarda Gitoxide'a daha fazla Git özelliğini vibe loop ile eklemeye yönelik girişimler var ve bunlar ilginç: https://github.com/GitoxideLabs/gitoxide/pull/2538
    Yine de bu projenin biraz daha çalışmayla değerli olabileceğini düşünüyorum. Bu duyuru nihai ürün değil, yalnızca bir kilometre taşı. Projenin ortasında bile bunun mümkün olup olmayacağından emin değildim.
    Çok şey öğrendik ve daha öğreneceğimiz çok şey var ama elle yapılmış, yüksek kaliteli, görüşü net, kısmi bir Git kütüphanesi olan Gix ile vibe ile yapılmış, tam uygulamaya daha yakın ama biraz dağınık bir LLM Git kütüphanesi olan Grit'in ikisinin de faydalı kullanım alanları olabilir. Bir süre daha her iki seçeneği de keşfetmeye ve yatırım yapmaya değer olduğunu düşünüyorum.
    Ayrıca ben bu işin içinde olan bir yöneticiyim ve yıllar boyunca Git topluluğu için epey şey yaptım. Kendi “özel kopyamı” elde etmeye çalıştığım fikri saçma.
    Pro Git kitabını(https://git-scm.com/book/en/v2) ve ondan önceki Git community book'u(https://schacon.github.io/gitbook/index.html) yazıp açık kaynak olarak yayımladım, resmî Git web sitesini(https://git-scm.com) oluşturdum, dünyadaki neredeyse tüm açık kaynakları barındıran GitHub'ın kurucu ortaklarından oldum ve yaklaşık 20 yıldır Git ekosistemini yaygınlaştırıp destekliyorum.
    15 yıl önce libgit2 geliştirmesini yeniden başlattım ve finanse ettim; buna da Git'in daha müsamahalı lisanslı bir “özel kopyasını” isteyen bir yönetici diyebilirsiniz ama bu iddia da aynı derecede saçma.
  • GitButler'ın şu anda gitoxide bakımcısını işe aldığını ya da onunla birlikte çalıştığını biliyorum. Dolayısıyla bunun farkında olmaları gerekir.
    Muhtemelen gitoxide'ın kendi kullanım senaryoları için yeterli olmadığına ya da genişletme/iyileştirme maliyetinin fazla yüksek olduğuna karar verdiler.

• Bellek güvenliği gibi şeyler güzel ama dürüst olmak gerekirse bunun hangi kullanım senaryosu için olduğunu anlamıyorum.
  Etmen tarzı geliştirmeyi göstermek için mi? 10 yıldan uzun süredir Git kullanıyorum ve bellek taşması gibi nedenlerle hiç sorun yaşamadım. Bazı yazılımlar için “olduğu haliyle yeterince iyi” denebilir ve Git'in buna girdiğinden oldukça eminim.
  20'den fazla geliştirici ve çok sayıda ikili çıktı ile çalışan ekiplerde bile Git'in sınırlarına neredeyse hiç çarpmadım. Git'in sınırlarını gerçekten zorlayan bir durumdaysanız, belki de Git'ten uzaklaşmanız gerekir ve Rust ile yeniden yazım hiçbir işe yaramaz. O yüzden tekrar sormak istiyorum: neden?

  • Yazıda zaten cevaplanmıştı ama Git'in bağlanabilir bir kütüphanesi yok ve uzun zamandır da yok.
    Küçük bir şey yapmak isteseniz bile süreci fork/exec ile başlatıp stdin/stdout üzerinden iletişim kurmanız gerekiyor. Ya da her şeyi baştan uygulayıp tüm istisna durumlarını ele almanız gerekiyor.
    Örneğin tek bir nesneyi okumak, loose nesneyse kolay ama bir packfile içindeyse çok daha zor. Referans okumak, yani bir branch'in hangi SHA'yı işaret ettiğini kontrol etmek de loose dosya, packfile veya reftable'dan biri olabilir.
    Bunu CLI amacıyla kullanacak kimse olmayacaktır. Kararlı hâle gelse bile neredeyse kesin olarak her zaman daha yavaş ve her açıdan daha kötü olacaktır. Şu anda zaten kararlı da değil.
    libgit2 ya da Gitoxide kullanılabilir; ikisi de ya benim başlamasına yardımcı olduğum ya da GitButler'ın şu anda ilerletilmesine katkı verdiği projeler. Neredeyse her açıdan daha hızlı ve daha iyiler ama özellik bakımından tam değiller.
    Bu, Git kullanan insanlar için değil; Git'in bazı parçalarını kullanmak isteyen araç geliştiricileri için.
  • Bu lisans aklama.
  • Bunu yapmadan Git lisansını nasıl aklayacaklar ve sonrasında bait and switch için nasıl hazırlık yapacaklar ki?

• Artık herkes kendi LLM klonunun türetilmiş eser olmadığını iddia edebildiğine göre yazılım lisanslarının anlamı kalmamış gibi görünüyor.

  • Şu anda projeyi başka bir dile çevirip lisansı değiştirmenin sorun olmadığını varsayan insanlar var.
    Casey Muratori yakın zamanda benzer bir bağlamda, Microsoft'un AI hamlesinin onların eski ve devasa bir kod tabanına sahip olmasıyla ilgili olabileceğini söyledi. Eski büyük yazılım şirketleri model eğitiminde avantajlı ve kendi fikrî mülkiyetleriyle ek değer sunabiliyor.
    Ama şimdi bu fikrî mülkiyet modelin içine girip herkesin erişimine açık hâle gelebilir. Gerçekten kendi fikrî mülkiyetinizle bir model eğitiyorsanız, herkes bunun API'sini uygulayıp GPL lisansı ekleyebilir.
    O noktadan sonra işler gerçekten ilginçleşir.
  • Neredeyse hiçbir FOSS telif hakkı sahibi ihlalcileri dava etmediği için lisansların anlamı zaten epey zayıftı.

• Bu, GPL kodunun intihali ve lisans aklamasıdır.
  Test paketinden geriye doğru çalışmayı anlayabilirim ama bu, kelimenin tam anlamıyla orijinal kaynağı okumak: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#source-of-truth
  LLM kullanıcıları sanki sabitlenmemiş olan her şeyi çalıp kendi çalışmalarıymış gibi sunabilecekleri başka bir dünyada yaşıyor gibi görünüyor

  • Ben farklı görüyorum. Aynı yaklaşımla bu kodu kendim yazdığımı düşünün. Belgeleri okur, testlere bakar, kaynağı inceler ve birlikte çalışabilir ama yaklaşımı çok farklı bir uygulama üretirdim
    Örneğin GitButler'da SSH commit imzalamayı düzgün çalıştırmaya uğraştığımda tam olarak bunu yaptım: https://blog.gitbutler.com/signing-commits-in-git-explained
    Yazıda da görebileceğiniz gibi, doğru davranışı anlamak için C kaynağını derinlemesine inceledim; sonra aynı işi Rust ile uyguladım ama kaynak kodunu kopyalamadım
    Grit'in Rust kaynağı ile Git kaynağı arasında bazı benzerlikler var ama bunların çoğu zaman/biçim işleme ya da packfile ayrıştırma için gereken bayt ofsetleri gibi şeyler. Bana göre doğrudan kod kopyalama yok
    Bunu yeniden girişe uygun, bellek güvenli ve kütüphane merkezli bir kod tabanına dönüştürmek için yaklaşım zaten o kadar farklı olmak zorunda ki, kopyalama çoğunlukla işe yaramaz
    Ama packfile ya da reftable ikili biçimleri düzgün belgelenmiş değil; bu yüzden kimse tahmin ederek doğru yapamaz. Bunu iyi biliyorum, çünkü muhtemelen packfile ikili biçimini belgelendirmeye çalışan az sayıdaki kişiden biriyim: https://schacon.github.io/gitbook/7_the_packfile.html
    Kaynağı okumak zorundasınız. Bu tanıma göre libgit2, Gitoxide ve diğer tüm Git yeniden uygulamaları da teknik özellikleri doğrulamak için Git kaynağına bakmak zorundaydı; o zaman bunların hepsi “lisans aklaması” oluyor
    Grit içinde satır satır kopyalanmış olduğu açık bir kod bulursanız haber verin, değiştiririm. Ama Git kaynağı Git spesifikasyonunun kendisi ve LLM olsun ya da olmasın, uyumluluk sağlamak isteyen tüm yeniden uygulamalar bu yaklaşıma mecbur kalıyor
  • Bunun büyük bir kitle tarafından kabul edilebilir gibi görünmesi korkutucu
    Değerli mülk yazılımlar, müzik, filmler, hatta LLM'lerin kendisi gibi başka fikri mülkiyet sahiplerinin sıradaki yüzünü leoparlar yiyecek olanların kendileri olduğunu düşünmemesini anlamıyorum
    Fikri mülkiyetin bu şekilde aşınması durmalı. Aksi halde zihinsel emekle çalışan herkes tamamen mahvolur. Yalnızca FOSS insanları için geçerli olsaydı, banyo suyuyla birlikte atılmalarından endişe ederdim; ama bu açıkça genel bir mesele
  • Emin değilim ama orijinal kaynak kodunun tamamı eğitim verisinin içinde de yok muydu?

• Daha önce bunun “cindən dilek dilemeye benziyor; temel kuralları gerçekten çok net koymak gerekiyor” benzetmesini yapmıştım
  Eskiden daha çok goleme benziyordu ama Fable'ın sabotaj modu https://jonready.com/blog/posts/claude-fable5-is-allowed-to-sabotage-your-app-if-youre-a-competitor.html yüzünden artık kesinlikle cine daha yakın görünüyor
  Eskiden bunu “model sana istediğini değil, istediğin şekilde talep ettiğin şeyi verir” diye ifade ediyordum. Şimdi Fable'da istediğini de vermediği için artık bilmiyorum

• Deney amacıyla bakıyorsak, ben daha çok ters yönde bir şeyi merak ediyorum. Bu projeler genelde “performans” için yeniden yazılıyormuş gibi görünüyor; muhtemelen AI sayesinde maliyet düştüğü için
  Quake III'ü Python'a portlamak ya da Kubernetes'i Perl'e, hatta Rails'i Python'a taşımak gibi tuhaf ama eğlenceli işler görmek isterdim

  • Quake III'ü Python'a portlamak muhtemelen mümkün olurdu
    Natural Selection 2'nin büyük kısmı diye hatırladığım kadarıyla Lua idi ve bu da zaten 10 yıldan daha uzun zaman önceydi
  • Bunun “performans” için bir yeniden yazım olduğu söyleniyor ama aslında performansı çok daha kötü
    Daha yavaş, testleri yetersiz ve eksik bir Git uygulaması sadece 10 bin ila 15 bin dolara yapılmış oldu
    Bu süreçte epey insan zamanı da boşa harcandı
    Zaten başka bir yerde bir grubun Rust portu yaptığı söyleniyordu. Bu kadar para ve yazılım geliştirme kaynağı oraya harcansaydı ne kadar çok şey başarılabilirdi?
    AI'nin yeterince kapsamlı test etmezseniz bir şeyi portlayabiliyor gibi göründüğü zaten kanıtlanmış gibi. Bu tür işlerde artık giderek daha az değer görüyorum. Yazarı için eğlenceli olmuş olabilir ama başkalarına nasıl yardımcı olduğunu bilmiyorum
  • Gerçekten performans için olsaydı, orijinal lisansı kullanırlardı. Ama öyle yapmadılar
    Bütün RiiR hareketi, kullanıcı için avantajlı bir lisans olan GPL'den uzaklaşma yönünde son derece açık bir hareket

• “Oldukça ilginç bir deney ve tüm topluluk için gerçekten faydalı bir şeye dönüştürülebileceğini düşünüyorum” kısmının ilk yarısına katılıyorum. Deneyin keyfini hep birlikte çıkarabiliriz
  Ama “bağlanabilir ve yeniden girişli bir kütüphane değil de, daha basit komutları birbirine ekleyen Unix felsefesine dayandığı için uzun süre çalışan süreçlerde her seferinde fork/exec ek yükü olmadan kullanmak zor” kısmında felsefi bir ayrılık ortaya çıkıyor
  Tüm yazı boyunca “neden” sorusuna değinen tek yer burası ve Unix yaklaşımı bir özellik; hatta bugün daha da önemli olduğu bile söylenebilir: https://aperocky.com/blog/post.html?slug=unix-philosophy-agentic

  • Alıntıyı kolaylık olsun diye kısaltmışsın
    “Bağlanabilir ve yeniden girişli bir kütüphane değil de, daha basit komutları birbirine ekleyen ‘Unix’ felsefesine dayandığı için, tüm işler için fork/exec ek yükü olmadan uzun süre çalışan süreçlerde kullanmak zor” cümlesinin tamamı asıl mesele
  • Git zaten libgit üstündeki bir arayüz değil mi? Farkın ne olduğunu anlamıyorum

• Git’i 15 yıldan uzun süredir kullanıyorum ve bir kez bile çökme yaşamadım. Tam olarak hangi sorunu çözmeye çalışıyorlar?

  • Amaç, özellikleri tam, yeniden girişli ve bağlanabilir bir kütüphane oluşturmak. Böyle sorularda çoğu zaman yazıyı okumak yardımcı olur
  • Çözmeye çalıştıkları şey, kullanıcı açısından avantajlı bir lisans olan GPL
  • Yıllar içinde epey çökme gördüm. Çoğunlukla bazı özel depolarda gc ve pruning bir süre boyunca beklenmedik sonlanmalara yol açıyordu
    Yine de genel kararlılık gerçekten mükemmeldi. Sadece bu özel yeniden yazımın “neden?”ine ben de cevap veremem
  • LLM psikozu gibi bir sorun var; insanlar LLM yüzünden kendilerine süper güç geldiğine inanıyor
    Bunlar tamamen farkında olmadan, safça işe girişiyor ve kendi başına düşünme yetilerini kaybetmiş durumdalar. Onların yerine düşünen LLM ise “X yapmak kötü bir fikir” demez. LLM, sahibine mümkün olduğunca çok token üretmek için var

• Bu iş GitHub’ın kurucu ortaklarından birinden çıkıyor; yani GPL’in ne için var olduğunu çok iyi biliyor olma ihtimali yüksek
  Hukuki artıları ve eksileri ne olursa olsun, bir GPL3 projesinin tüm test paketinin üstüne inşa edip sonra MIT ile yeniden lisanslamak, asıl yazarlara karşı iyi niyetli davranmak değildir
  Gerçekten iğrenç ve bu yüzden GitButler’ın tamamından uzak durmak istiyorum

  • Bu, GPL lisanslı bir test paketini GPL’in açıkça izin verdiği belirli bir amaç için kullanma özgürlüğüne inanmadığın şeklinde geliyor
    Bir lisansı seçip sonra hoşuna gitmedi diye sonradan ek şartlar getiremezsin. Bu, GPL lisansının açıkça izin vermediği bir şeydir