jj'de geleceği görüyorum

• Rust ile yazılmış yeni sürüm kontrol sistemi jj, mevcut Git’in sınırlamalarını tamamlayan ve kademeli olarak benimsenebilen bir yapıya sahip bir araçtır
• Yazar, geçmişte Rust’ın büyüme potansiyelini analiz etmiş olma deneyimine dayanarak, jj’nin de ürün-pazar uyumu, uzman ekip ve kullanıcı tabanı açısından benzer bir potansiyele sahip olduğunu değerlendiriyor
• jj, Git depolarıyla uyumlu kalırken daha basit bir iş akışı sunuyor; özellikle Git’in iç yapısına aşina olmayan geliştiriciler için erişilebilirliği yüksek
• Google ve Oxide gibi yerlerde gerçek kullanım yayılıyor; tutkulu bir topluluk ve kendini adamış bir geliştirme ekibi oluşuyor
• Yazar, jj tabanlı bir iş birliği platformu geliştiren ERSC'ye katılarak, Rust’ın ilk dönemlerindeki gibi jj ekosisteminin büyümesine doğrudan katkı sağlamayı planlıyor

---

Rust’ı seçme nedeni

• Yazar, 2012 Noel’inde Hacker News’te “Rust 0.5 released” haberini görüp bu dile ilgi duymaya başlıyor
  • O dönemde Ruby on Rails geliştiricisiydi, ancak üniversite yıllarından beri derleyiciler ve sistem programlama ile ilgileniyordu
• Rust’ın başarılı olma ihtimalini değerlendirirken üç unsuru dikkate alıyor: ürün-pazar uyumu, geliştirme ekibi, kullanıcı tabanı
  • C/C++’ın yerini alabilecek güvenilir bir dil yoktu ve Rust, çöp toplayıcı olmadan bellek güvenliği sunan yenilikçi bir yaklaşım ortaya koyuyordu
  • Mozilla’nın sponsorluğu ve Rust’ı Firefox’a dahil etme planı olduğu için, gerçek kullanım tabanı edinme ihtimalinin yüksek olduğunu düşünüyordu
• Rust topluluğunun nazik ve iş birliğine açık atmosferi de önemli bir çekim unsuru oldu
  • Daha sonra yazar, “Rust for Rubyists” eğitimini yazdı ve resmî belgelerin ortak yazarlarından biri oldu

jj’nin ortaya çıkışı

• jj (Jujutsu), bir programlama dili değil, Rust ile uygulanmış yeni bir sürüm kontrol sistemi (VCS)
  • Git ile uyumlu ve mevcut depoları olduğu gibi kullanarak kademeli biçimde benimsenebiliyor
• Yazar, teknik zevkleri benzer olan geliştirici Rain’in tavsiyesiyle jj’yi keşfetmeye başlıyor
  • Rain, Meta’nın kaynak yönetimi ekibinden geliyor ve onun tavsiyesi güvenilir bir sinyal olarak görülüyor
• Hafta sonunda jj’yi bizzat deneyerek bir eğitim yazısı projesi başlatıyor
  • Rust öğrenirken yaptığı gibi, yazarak kavramları düzenleme yaklaşımını benimsiyor
  • Sonuç olarak bu eğitim topluluk içinde olumlu karşılık buluyor

jj’nin geleceğine dair görünüm

• Yazar, jj’de Rust’ın ilk dönemlerine benzer bir büyüme deseni görüyor
  • Ürün-pazar uyumu, ekip yetkinliği ve kullanıcı yayılımı ihtimali açısından tablo olumlu
• Ürün-pazar uyumu açısından Git mutlak üstünlüğe sahip olsa da, jj Git depolarını olduğu gibi işleyebildiği için kısmi benimseme mümkün
  • Oxide içinde de kullanım Rain ile başlayıp yayılıyor; hatta özel bir kanal açılacak kadar ilgi görüyor
• Google içinde de jj kullanılıyor; bu, Mozilla’nın Rust’ı benimsemesine benzer bir sinyal olarak yorumlanıyor
  • Google’ın büyük monorepo’sunda (Piper backend tabanlı) da bazı projeler jj kullanıyor; bu da sosyal kanıt (social proof) işlevi görüyor
• Bir öğrenme eğrisi var, ancak Git’in iç yapısına aşina olmayan kullanıcılar için aksine daha sezgisel ve daha basit bir kullanım deneyimi sunuyor
  • Git uzmanlarının yeni kavramlara uyum sağlaması gerekirken, genel geliştiriciler hızlıca alışıyor
• jj topluluğu tutkulu ve samimi bir atmosferle büyüyor; bu da Rust’ın ilk dönem topluluğunu hatırlatıyor

jj ekibi ve topluluğu

• Kurucu Martin, uzun süredir jj geliştirmeye kendini adamış durumda; yakın zamanda da kişisel hesaptan resmî organizasyon hesabına geçiş yaparak yönetişim yapısını düzenledi
• Ekip üyeleri, kaynak kontrol araçları geliştirme deneyimi yüksek uzmanlar; teknik yön ve kalite yönetimi konusunda güçlüler
• Topluluk, aktif geri bildirim ve iş birliğiyle hızla büyüyor; erken dönem Rust topluluğunun olumlu enerjisini yeniden üretiyor

Yeni meydan okuma: ERSC’ye katılım

• Yazar, Oxide’dan ayrılıp jj tabanlı bir iş birliği platformu geliştiren startup ERSC’ye katılmaya karar veriyor
  • Oxide harika bir iş yeriydi, ancak jj ekosistemine daha derinden katılma arzusu belirleyici etken oldu
• ERSC, jj üzerinde bir geliştirici iş birliği platformu kurmayı planlıyor; GitHub’ın Logical Awesome adlı tüzel kişilikle yola çıkmış olması örneğini anarak benzer bir erken aşamayı açıklıyor
• Yazar, Oxide’daki işlerini tamamladıktan sonra biraz dinlenip ardından jj topluluğu faaliyetlerine ve eğitimi tamamlamaya odaklanmayı planlıyor
  • Discord’daki faaliyetlerini artıracağını, blog yazı dizisi yayımlayacağını ve topluluğa katkı sunacağını belirtiyor
• 2025’i yeni bir dönüm noktası olarak değerlendiriyor ve gerçekten tutkuyla bağlı olduğu bir projeye yönelebilme fırsatı için minnettarlığını ifade ediyor

Sonuç

• Yazar, jj’nin Rust’ın büyüme rotasını yeniden üretebilecek potansiyele sahip olduğuna inanıyor
  • Bunun dayanakları Git ile uyumluluk, kademeli benimseme imkânı, kendini adamış ekip ve canlı topluluk
• jj, yalnızca basit bir araç olmanın ötesinde, geliştirici iş birliği biçimini dönüştürebilecek bir platforma dönüşme potansiyeli gösteriyor
• Rust ile başlayan yazarın yolculuğu artık jj ile birlikte yeni bir bölüme giriyor

[tujuc]

Bu daha önce birkaç kez çıkmıştı ama bir kez bakmak gerekecek gibi.

[GN⁺]

Hacker News görüşleri

• jj'yi yaklaşık iki kez ciddi ciddi denedim. birinci sınıf conflict kavramı havalı ama pratikte staging/commit işlemlerini çatışma çözümünden çok daha sık yapıyorsunuz. magit'ten geldiğim için jj'nin hunk bölme ve seçme özellikleri bana çok kullanışsız geldi. Ben sık sık rebase yapıyorum, bu yüzden magit'in rebase kısayollarıyla zaten jj'nin avantajlarının çoğunu kullanıyordum. Benim gibi biri için jj'nin magit'i geçmesi, hunk seçimi UX'inin çok daha fazla iyileşmesine bağlı

  • jj'de mesele staging ya da commit düşünmemek. Her şey bir değişiklik(change) ve ebeveyni ya da daha uzak ataları bookmark olarak belirleyip onun içine squash etmek ya da bookmark'ı bir sonraki değişikliğe taşımak şeklinde düşünmek gerekiyor
  • Ben de sık rebase yapıyorum ama jj'nin fazla görüş dayatan sürüm kontrol felsefesini sevmiyorum. Özellikle yeni başlayanlar için iç tasarımı fazla gizlemek öğrenmeye yardımcı olmuyor bence
  • magit'in hunk seçimi UX'inin somut olarak nasıl olduğunu merak ediyorum. jj'ninkinden çok farklı görünmüyordu. Ben uzun süre GitUp(gitup.co) kullandım; jj'nin UX'i tamamen doğal hissettirmiyor ama bu bana daha çok kısayol özelleştirmesiyle çözülebilecek bir konu gibi geliyor
  • Git'in üstüne iyi bir UX koymanın neden önemli olduğunu anlıyorsanız, jj'nin felsefesinin %95'ini zaten anlamışsınız demektir
  • jj'de git index de kullanılabiliyor. Yalnızca git_head'i değiştiren jj komutlarını kullanmamak gerekiyor. Ben staged değişikliklerle commit atan bir alias oluşturdum (config.toml örneği)

• Git'in alternatiflerini her gördüğümde biraz Luddite duygusu hissediyorum. Zaten çok fazla dil, framework ve araç var. En azından VCS tarafında Git gibi neredeyse evrensel bir çözümümüz olması iyi bir şey. jj bazı sorunları çözebilir ama sektörün iki sistemi birden desteklemek zorunda kalmasının getireceği yük düşünülünce net bir kazanç olmayabilir

  • Git'in berbat UI'ı o kadar sinir bozucu ki yerine bir şeyin gelmesini isterim. Git'in kavramlarını daha iyi anlatan yeni bir araç çıkmasını isterdim
  • jj, geliştiricinin bireysel olarak seçebileceği bir seçenek. jj repo'ları git repo'larının üstkümesi, yani mevcut araçlar bozulmuyor
  • Eskiden svn kullanan bir şirkette önce git-svn ile Git kullanmıştım. jj de benzer bir yaklaşım izliyor gibi. jj'yi bilmeseniz bile mevcut CI ya da araçlar olduğu gibi çalışıyor
  • Git bir verimlilik düşürücü ve özellikle ajan tabanlı kodlama çağında daha da büyük bir sorun. Bana göre jj yeterince devrimci değil. Bunun yerine değişiklikleri atomik düzeyde izleyen yeni bir VCS lazım. Böyle bir yapıda branch kavramı ortadan kalkar, repo durumu planlar ve atomlarla kurulabilir. Tabii böyle bir sisteme geçiş çok büyük bir meydan okuma olur
  • rcs, cvs, svn'den sonra git geldiyse, git de bir gün daha iyisiyle değiştirilecektir

• jj'yi denedim ama ben Sublime Merge'e alışığım. CLI ile sürüm kontrolü yaparken tekrar eden girişler çok oluyor ve durumu gözden kaçırmak kolay. GUI'de durum hep görünür oluyor ve tek tıkla diff'e ya da commit mesajı girişine geçilebiliyor. Klavyeyle hunk seçmek bir daha yapmak istemediğim bir şey. SM gerçekten çok rahat. Keşke jj GUI'si gelişse ya da SM'e jj entegrasyonu gelse

• Asıl haber, insanların “jjhub” gibi şeyler yapmaya başlaması (ersc.io)

  • 'jjhub' bence iyi bir ilk adım. Zaten jj'yi github ile kullanabiliyorsunuz ama bunun ötesinde gerçekten değerli bir şey sunması gerekiyor
  • Bu arada buna da bakın: Stacking blog yazısı
  • Gerrit de jj kavramlarıyla çok uyumlu ve Jujutsu change ID desteği eklemek için bir RFC kabul edildi
  • jjhub adı bayağı iyiymiş
  • Gerçekten başarılı olmasını isterim. Github'a gerçek bir alternatif çıkmasının zamanı geldi

• Google içinde jj'nin yayıldığı söyleniyor ama Google'ın dahili VCS'sini düzenli aralıklarla değiştirme gibi bir eğilimi var. 7 yıl içinde git wrapper, mercurial uzantıları ve şimdi de jj arasında geçiş yaptılar

  • Aslında Google içindeki araçların çoğunun ömrü kısa. Yine de jj, değişikliğin kimliğini(identity) koruması açısından yenilikçi. git'te rebase ya da amend sonrası commit tamamen farklı hale gelirken jj'de aynı değişiklik olarak izlenebiliyor. Ama jj'nin sonunda yine git'i depolama backend'i olarak kullanmaya devam etmesi muhtemel
  • Umarım jj kalıcı olur. İşte de evde de aynı workflow'u kullanmak istiyorum. mercurial'dan çok daha hızlı
  • Bu sefer amaç Perforce fork'unu da birlikte bırakmak gibi görünüyor. Dışarıdan bakınca değişim fazla geliyor
  • git wrapper baştan beri deneyseldi, mercurial tabanlı sistem ise neredeyse 10 yıl kullanıldı

• jj'nin büyük binary dosyaları git'ten daha iyi yönetip yönetmediğini merak ediyorum. Oyun geliştirme tarafında Perforce hâlâ kral. git, LFS olsa bile yeterli değil

  • Perforce'un binary desteği pratikte Git LFS ile aynı. Fark daha çok kurumsal destek olup olmaması
  • jj, git'i depo olarak kullanıyor ve LFS desteği yok; dolayısıyla bu konuda git ile aynı sınırlamalara sahip
  • Şu an için özel bir iyileştirme yok ama bu alanın farkındalar ve ileride değişebilir

• Yaklaşık bir gün boyunca Jujutsu tutorial'ını takip ettim ve oldukça iyi buldum. Ama yine de sanki eksik bir puzzle parçası varmış gibi geldi. Mesela GitHub'a PR açarken change id'nin gerçekten işe yarayıp yaramadığını merak ettim. Muhtemelen asıl değerini sadece Google içindeki Piper backend'de gösteriyor. ERSC'nin planlarını merak ediyorum. Benim kişisel isteğim, çevrimdışı code review'yu içine alan dağıtık bir workflow

  • Keyif alarak kullanmış olmanıza sevindim :) Şu anda GitHub'da change id'nin faydası neredeyse yok. Ama jj-spr gibi araçlarla deneyimin bir kısmını elde edebilirsiniz. Ayrıca GitHub SVP'sinin jj'ye ilgi gösterdiği bir tweet de vardı. Bir de, issue'ları repo'nun içine koyan bir sistem olarak beads'i denedim ve oldukça beğendim
  • jj ile oluşturulan commit'lerde change-id başlığı bulunuyor; bu sayede GitHub jj'yi bilmese bile jj kullanıcıları kendi aralarında rebase takibi yapabiliyor. git cat-file -p HEAD ile görülebilir

• Kişisel projelerimde jj'yi 1-2 aydır kullanıyorum ve oldukça memnunum. Yalnız eski revision'ları düzenlerken .gitignore'a yeni eklenen dosyalar yanlışlıkla dahil olabiliyor. Onun dışında iyi. Yine de şimdilik Git bilgim çok daha fazla, bu yüzden şirkette de yavaş yavaş kullanmaya başlayacağım

• Bu yıl Sapling/Subversion şirketine katıldım ama jj'yi hâlâ denemedim. Yine de Sapling çok daha sezgisel ve commit stack'leri branch'lerden daha kolay anlaşılıyor. Tabii Meta'nın review UI'ı gibi destekler olmadan nasıl olur merak ediyorum. Böyle projelere kesinlikle ihtiyaç var

  • Evet, Sapling ile jj aynı yöne giden kardeş projeler

• Adı ne olursa olsun, East River Source Control gerçekten harika bir isim