Rilis jj v0.42.0 - Sistem kontrol versi yang kompatibel dengan Git

 (github.com/jj-vcs)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Beralih ke allocator memori mimalloc untuk meningkatkan performa multithread
  • Menghapus opsi perintah yang akan dihentikan seperti jj commit --reset-author/--author, jj describe --no-edit/--edit/--reset-author/--author
  • Menghapus opsi jj git push --allow-new, jj metaedit --update-committer-timestamp
  • Menghapus opsi konfigurasi yang akan dihentikan seperti git.auto-local-bookmark, git.push-new-bookmarks
  • jj evolog tidak lagi mendukung predecessor commit lawas yang dicatat sebelum jj 0.30
  • Auto-completion shell kini menampilkan deskripsi untuk alias, revset-alias, template-alias, dan fileset-alias kustom, serta mengekstrak deskripsi dari field .doc pada definisi alias berbentuk tabel
  • jj show kini menerima beberapa revisi dan menampilkan tiap revisi secara berurutan, lebih mendekati git show
  • jj git fetch membuat evolution history berbasis change ID, dan jika remote mempertahankan change ID, revisi descendant lokal akan di-rebase ke atas parent yang telah ditulis ulang
  • Perintah jj util backend name menampilkan nama backend commit yang digunakan oleh repositori saat ini
  • Menambahkan konfigurasi edit-invocation-mode untuk diff editor; saat disetel ke "file-by-file", editor dijalankan sekali untuk setiap file yang berubah sehingga alat per file seperti vimdiff bisa digunakan
  • jj git remote add kini melaporkan error alih-alih panic saat nama remote kosong atau mengandung spasi
  • Diff color-words saat output warna dimatikan kini menampilkan before/after pada baris terpisah, meningkatkan keterbacaan diff yang dipipe atau di-redirect

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Pendapat di Lobste.rs

  • Saya penasaran, jika jj git fetch sekarang membuat riwayat evolusi berbasis change ID, apakah itu berarti kalau remote mempertahankan change ID, kita tidak perlu lagi menjalankan jj new main setiap kali tepat setelah jj git fetch?
    Kalau begitu, ini terlihat seperti peningkatan kualitas hidup yang cukup bagus

    • Saya tidak membacanya seperti itu. Saat fetch, change yang berbeda dari sebelumnya akan tetap muncul di main, jadi sepertinya tidak membantu untuk bagian itu
    • Kalau menambahkan trailer ke pesan commit, remote apa pun akan mempertahankannya
      Hanya saja saya tidak tahu bagaimana jadinya pada merge commit buatan GitHub yang tidak punya change ID

  • Saya malah lebih penasaran dengan bagian yang menyebut mereka beralih ke allocator memori mimalloc untuk meningkatkan performa multithread
    Untuk proses yang berjalan lama, saya pernah memakai hal seperti jemalloc untuk mengurangi fragmentasi, tetapi jj terasa seperti mulai dalam 1 ms dan selesai dalam kurang dari 10 ms, jadi cukup mengejutkan bahwa pergantian allocator bisa terasa dampaknya
    Saya cari sedikit lagi, PR-nya adalah https://github.com/jj-vcs/jj/pull/9484, dan saya hanya menemukan sekitar https://github.com/jj-vcs/jj/issues/2490#issuecomment-2595323515, tetapi itu tidak terlihat seperti peningkatan kecepatan yang besar. Meski begitu, kalau memang lebih cepat dan perubahannya hanya beberapa baris, ya bagus juga

  • Disebut “jika remote mempertahankan change ID”, tetapi saya tidak tahu apakah remote biasanya benar-benar mempertahankannya
    Saya tahu jj gerrit upload menambahkan footer change ID, tetapi jj git push biasa tidak melakukannya

    • Selama commit tidak ditulis ulang, seharusnya itu tetap dipertahankan
      Namun operasi yang menulis ulang commit, seperti squash merge atau rebase merge di GitHub, tidak akan mempertahankannya. Jika diproses dengan alat standar berbasis libgit2, custom header tidak dipertahankan, sedangkan beberapa alat seperti pustaka Rust yang dipakai GitButler mendukung pelestarian custom header, tetapi saya ragu apakah forge memakai hal seperti itu
    • Saya penasaran remote mana yang mempertahankan change ID
      Saya juga tidak tahu bagaimana cara memeriksa apakah itu benar-benar dipertahankan dengan baik
    • Sepertinya change ID yang dimaksud di sini bukan Gerrit change ID, melainkan jujutsu change ID
      Dokumentasinya punya informasi lebih rinci
    • GitLab mempertahankannya. Di kantor saya sekarang kami memakainya seperti itu
      GitHub juga mempertahankannya; Anda bisa mengeceknya lewat commit pushcx di codebase lobsters atau commit saya

  • Saya penasaran apakah ada bahan bacaan atau tontonan yang bagus tentang alasan memakai jj alih-alih Git standar
    Saya tahu jj bisa berjalan di atas Git dan saya juga sudah mencobanya di proyek hobi, tetapi saya masih belum benar-benar menemukan daya tarik penentu tentang kenapa itu lebih baik atau lebih mudah