jj v0.42.0 sürümü yayımlandı - Git uyumlu sürüm kontrol sistemi

 (github.com/jj-vcs)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • mimalloc bellek ayırıcısına geçilerek çok iş parçacıklı performans iyileştirildi
  • jj commit --reset-author/--author, jj describe --no-edit/--edit/--reset-author/--author gibi kullanımdan kaldırılması planlanan komut seçenekleri kaldırıldı
  • jj git push --allow-new, jj metaedit --update-committer-timestamp seçenekleri kaldırıldı
  • git.auto-local-bookmark, git.push-new-bookmarks gibi kullanımdan kaldırılması planlanan yapılandırma seçenekleri kaldırıldı
  • jj evolog, jj 0.30 öncesinde kaydedilen eski commit predecessor desteğini sonlandırdı
  • Kabuk otomatik tamamlama, kullanıcı tanımlı alias, revset-alias, template-alias ve fileset-alias açıklamalarını gösteriyor; ayrıca tablo biçimindeki alias tanımlarının .doc alanından açıklama çıkarıyor
  • jj show, birden fazla revizyon alabiliyor ve git showa daha yakın olacak şekilde her revizyonu sırayla gösteriyor
  • jj git fetch, change ID tabanlı evolution history oluşturuyor; uzak depo change ID'yi koruyorsa yerel descendant revizyonları yeniden yazılmış ebeveynin üzerine rebase ediyor
  • jj util backend name komutu, mevcut depoda kullanılan commit backend adını yazdırıyor
  • Diff editor için edit-invocation-mode ayarı eklendi; "file-by-file" belirtildiğinde değişen her dosya için düzenleyici bir kez çalıştırılıyor ve vimdiff gibi dosya bazlı araçlar kullanılabiliyor
  • jj git remote add, boş uzak depo adı veya boşluk içeren uzak depo adı verildiğinde panic yerine hata bildiriyor
  • Renkli çıktı kapalıyken color-words diff, before/after içeriğini ayrı satırlarda göstererek pipe edilen veya yönlendirilen difflerin okunabilirliğini artırıyor

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Lobste.rs görüşleri

  • jj git fetch artık change ID tabanlı evrim geçmişi oluşturuyorsa, uzak depo change ID'leri koruduğunda her jj git fetch işleminden hemen sonra jj new main yapmaya gerek kalmayıp kalmadığını merak ediyorum
    Öyleyse bu oldukça iyi bir yaşam kalitesi iyileştirmesi gibi görünüyor

    • Ben öyle okumadım. fetch yapınca eskisinden farklı bir change main üzerinde oluşacak, dolayısıyla o kısımda pek yardımcı olacak gibi görünmüyor
    • Commit mesajına bir trailer eklerseniz bunu her türlü uzak depo korur
      Yalnız change ID içermeyen GitHub tarafından oluşturulan merge commit'lerde ne olacağını bilmiyorum

  • Çok iş parçacıklı performansı artırmak için mimalloc bellek ayırıcısına geçildiği kısmını daha merak ediyorum
    Uzun süre çalışan süreçlerde parçalanmayı azaltmak için jemalloc gibi şeyler kullandım, ama jj bana 1 ms'de başlayıp 10 ms içinde biten bir araç gibi geliyor; bu yüzden ayırıcı değişikliğinin hissedilir olması şaşırtıcı
    Biraz daha bakınca PR'nin https://github.com/jj-vcs/jj/pull/9484 olduğunu ve yalnızca https://github.com/jj-vcs/jj/issues/2490#issuecomment-2595323515 gibi bir şeyi bulabildiğimi gördüm; büyük bir hız artışı gibi görünmüyor. Yine de daha hızlıysa ve değişiklik de birkaç satırsa gayet iyi

  • “Uzak depo change ID'leri koruyorsa” denmiş ama genelde uzak depoların bunu koruyup korumadığını bilmiyorum
    jj gerrit upload komutunun change ID footer'ı eklediğini biliyorum, ama normal jj git push bunu yapmıyor

    • Commit yeniden yazılmadığı sürece korunduğunu varsayabilirsiniz
      Ancak GitHub'ın squash merge veya rebase merge işlemleri gibi commit'i yeniden yazan işlemler bunu korumaz. Standart libgit2 tabanlı araçlarla işlendiğinde custom header korunmaz; GitButler'ın kullandığı Rust kütüphanesi gibi bazı araçlar custom header korumayı destekliyor, ama forge'ların böyle bir şey kullanıp kullanmadığı belirsiz
    • Hangi uzak depoların change ID'leri koruduğunu merak ediyorum
      Gerçekten korunduğunu nasıl doğrulamak gerektiğini de bilmiyorum
    • Burada kastedilen change ID'nin Gerrit change ID'si değil, jujutsu change ID olduğu anlaşılıyor
      Belgelerde daha ayrıntılı bilgi var
    • GitLab koruyor. Şu anda iş yerimde bunu bu şekilde kullanıyoruz
      GitHub da koruyor; lobsters kod tabanındaki pushcx commit'lerine veya benim commit'lerime bakarak doğrulayabilirsiniz

  • Standart Git yerine neden jj kullanılması gerektiğini anlatan okunacak ya da izlenecek bir kaynak olup olmadığını merak ediyorum
    jj'nin Git üzerinde çalışabildiğini biliyorum ve hobi projelerinde de denedim, ama neden daha iyi ya da daha kolay olduğuna dair o belirleyici çekiciliği hâlâ tam bulabilmiş değilim