jj – CLI untuk Jujutsu

• jj, antarmuka baris perintah untuk Jujutsu, adalah alat berbasis distributed version control system (DVCS)
• Menawarkan fitur yang lebih sederhana dan intuitif daripada git, namun lebih kuat
• Menggabungkan keunggulan git dan Mercurial untuk mengurangi jumlah alat inti dan memperkuat integrasi organik
• Menggunakan backend yang kompatibel dengan git sehingga memungkinkan eksperimen mandiri sambil tetap mempertahankan lingkungan kolaborasi yang ada
• Bagi pengguna tingkat lanjut, hal pentingnya adalah bisa memanfaatkan fitur manajemen versi tambahan yang sulit dilakukan dengan git

---

Pengenalan dan karakteristik jj

• jj adalah CLI (antarmuka baris perintah) untuk Jujutsu, dan Jujutsu adalah distributed version control system (DVCS)

  • Pengguna mungkin sudah terbiasa dengan DVCS lain seperti git, dan tutorial ini mengasumsikan sudut pandang pengguna git
  • jj dirancang sebagai alat yang lebih sederhana, lebih mudah digunakan, namun tetap kuat dibanding git
  • Secara umum, “kekuatan” dan “kompleksitas” sering saling bertentangan, tetapi jj menawarkan keseimbangan baru
  • jj menggabungkan keunggulan git dan Mercurial (hg) untuk membentuk jenis DVCS yang baru
  • Mengurangi jumlah alat inti dan menyediakan lingkungan kerja yang efisien melalui integrasi organik antar alat
  • Pengguna tingkat lanjut dapat memanfaatkan fitur manajemen versi tambahan yang sulit dilakukan dengan git
  • jj menggunakan backend yang kompatibel dengan git sehingga eksperimen mandiri dimungkinkan tanpa mengubah lingkungan kolaborasi
  • Tetap menjaga kompatibilitas dengan repositori git yang ada, dan bila perlu dapat dengan mudah kembali ke git
  • Tutorial ini menandai proses untuk memperlihatkan secara langsung mengapa jj adalah alat yang layak diperhatikan melalui karakteristik tersebut

[GN⁺]

Komentar Hacker News

• Banyak diskusi berfokus pada perbedaan antara git dan jj, tetapi menurut saya lebih baik lupakan saja git dan fokus pada workflow dasar jj
  Di repositori yang bersih, jalankan jj untuk memeriksa status, lalu setelah ada perubahan cukup commit dengan jj commit -m "made changes"
  Kalau melakukan kesalahan, perbaiki lalu gabungkan ke commit terakhir dengan jj squash
  Hanya saat ingin bekerja dari revisi tertentu seperti branch baru, gunakan jj new -r lmnop
  Riwayat git bisa dilihat dengan git log, dan cara kerja internal jj tidak terlihat

  • Saya juga menginginkan sesuatu yang mirip, jadi saya membuat git alias seperti alias.save="!git add -A; git commit -m" dan memakainya sebagai $ git save "made changes"

• JJ terasa seperti meminta saya untuk berpikir terbalik
  Di git, kita menulis pesan commit setelah membuat perubahan, tetapi di jj kita lebih dulu membuat commit baru lalu menambahkan deskripsinya
  Saya terbiasa memilih hanya perubahan yang diperlukan untuk di-commit dari keadaan yang berantakan dengan beberapa fitur bercampur, dan hanya dari tutorial jj saya belum yakin itu memungkinkan

  • jj new adalah konsep seperti area staging git yang kosong
    Di jj, commit selalu ada, dan commit itu memiliki changeid yang stabil sebagai nilai yang dihitung dari isi folder
    Jika ingin membagi beberapa perubahan menjadi commit terpisah, gunakan jj split
  • Saya sering membuat commit sementara dengan jj new dan membiarkan pesannya kosong
    Nanti saat sudah siap, saya squash beberapa commit menjadi satu lalu menambahkan pesan
    Cara ini bekerja seperti semacam riwayat undo, jadi jauh lebih nyaman untuk bereksperimen
  • Sebenarnya jj new hanya berarti “membuat commit baru di atas”, jadi tidak perlu langsung menulis deskripsi
    Saya juga dulu mencoba membiasakannya, tetapi justru tidak efisien
  • Di JJ, cara ini bersifat standar
    Git juga sudah lama merekomendasikan workflow serupa, dan lewat Squash Workflow Anda bisa membuat alur yang mirip dengan indeks git
  • Saat saya membuat banyak perubahan, beberapa fitur berbeda juga sering tercampur
    Karena itu saya memakai beberapa workspace dan sering menggunakan fitur shelve (IntelliJ)
    Kadang saya juga menyimpan diff sementara sebagai patch git
    Saya menyembunyikan proses yang kacau ini dari rekan kerja agar terlihat sedikit lebih profesional

• Setelah mencoba jj, hal yang tidak saya sukai adalah modifikasi file otomatis menjadi commit
  Jika saya checkout commit lama untuk menelusuri riwayat lalu mengubah file, commit itu berubah dan seluruh riwayat sesudahnya ikut direbase
  Karena itu saya harus defensif dengan membuat commit kosong baru
  Di git lebih nyaman karena repositori tidak berubah sampai saya secara eksplisit melakukan commit

  • Saya juga dulu berpikir begitu, tetapi berubah setelah mengetahui jj evolog
    jj ternyata sudah punya solusi yang lebih baik daripada staging
    Terlalu terbiasa dengan git CLI justru menjadi hambatan dalam mempelajari jj
    Menariknya, memakai jj justru membuat kita lebih paham struktur mesin penyimpanan git
  • Jika memakai edit alih-alih jj new, perubahan bisa dilacak dengan rapi
    Rasanya jauh lebih baik daripada jongkok-menjongkok stash di git
  • jj edit adalah jebakan terbesar di jj
    Sebagai gantinya gunakan jj new, dan kalau salah bisa dipulihkan dengan jj undo
    jj memperlakukan commit sebagai snapshot yang murah, jadi lebih tepat berfokus pada “perubahan” daripada commit
    Auto-rebase akan terkunci menjadi immutable setelah push, jadi aman
  • File yang otomatis ter-commit adalah fitur inti jj
    Cukup kombinasikan jj new dan jj squash lalu kelola seperti head branch git
    jj memudahkan bekerja dalam keadaan detached head
  • Mungkin Anda checkout commit lama dengan jj edit
    Jika diganti ke jj new, masalahnya akan teratasi

• Paragraf terakhir tentang jj adalah intinya
  Karena ia memakai backend yang sepenuhnya kompatibel dengan git, Anda bisa mencobanya sendiri tanpa seluruh tim harus ikut berubah
  Kalau tidak suka, Anda bisa kembali ke git kapan saja

  • Namun ada pengecualian untuk organisasi yang memakai LFS, submodule, atau hook
  • Tidak sepenuhnya kompatibel. Interoperabilitasnya memungkinkan, tetapi tidak benar-benar mulus
    Operasi git tidak dicatat di log jj sehingga harus di-import secara manual
    Untuk sebuah proyek, disarankan hanya memakai satu antarmuka
  • Dulu saya juga memakai git seperti itu bersama CVS dan Subversion
  • Tetapi jika git dan jj dipakai bersamaan dalam direktori yang sama, semuanya bisa rusak

• Fitur favorit saya adalah jj absorb
  Ia otomatis memindahkan perubahan di revisi saat ini ke commit terkait sebelumnya
  Berguna saat lupa memperbarui file konfigurasi atau .gitignore
  Cukup jj new, buat perubahan, lalu jj absorb
  Dan yang paling bagus, kita tidak perlu menangani merge conflict

  • Jika jj absorb diterapkan dengan salah, bisa dibatalkan dengan jj undo
    Berkat fitur ini, saya tidak lagi takut pada rebase yang rumit
  • Sebagai catatan, di git juga ada git absorb

• Saya sudah lama tidak sempat memperbarui tutorial, tetapi masih memakai jj setiap hari
  Saya sibuk di startup ersc.io sehingga belum sempat mengerjakan upstream
  Kalau ada pertanyaan, saya selalu terbuka

  • Perbedaan invariansi DAG antara git dan jj adalah kuncinya
    jj memakai stable change ID, sedangkan git memakai immutable commit ID
    Karena itu di jj, undo dan rebase terasa jauh lebih fleksibel
  • jj otomatis menyembunyikan perubahan yang “tidak menarik”
    Kadang saya ingin melihat lebih banyak perubahan, dan saya penasaran apakah ada opsi untuk menampilkannya sekaligus

• jj cukup berbeda dari git sehingga layak dicoba
  Hanya dengan merasakan pendekatan yang berbeda, wawasan engineering kita bisa meluas
  Kita tidak perlu mencoba semuanya, tetapi penting untuk memahami trade-off dari berbagai workflow

  • Tentu saja, dalam 99% kasus, percobaan dengan manfaat minim bisa jadi hanya buang waktu

• Hubungan git dan jj terasa seperti hubungan antara C dan Python
  git itu pelacakan forensik, sedangkan jj seperti bab-bab sebuah cerita
  Kadang kita perlu menulis ulang bab awal agar bagian akhir terasa lebih alami

  • Apa yang dilakukan jj sebenarnya juga bisa dilakukan di git, tetapi cara berpikir yang sudah terbiasa dengan git justru menghalangi
    jj dirancang dengan filosofi bahwa “working tree itu sendiri adalah commit” dan “conflict pun bisa menjadi commit”

• Klaim bahwa ini “lebih kuat dan lebih mudah” terasa perlu contoh yang konkret

  • Kalau harus menyebut beberapa keunggulan jj:
    • rebase/merge conflict tidak harus langsung diselesaikan
    • manipulasi commit sangat mudah (terutama saat memakai jjui)
    • jj memiliki operation log yang melacak perubahan status git
    • branch tanpa nama membuat pekerjaan eksperimental lebih bebas
    • sepenuhnya kompatibel dengan git sehingga bisa dipakai campur dalam satu tim
  • Saat kami pindah dari SVN ke git, kami merasakan peningkatan besar, tetapi sekarang tidak ada masalah besar dalam workflow git
  • Anda bisa mengerjakan beberapa PR sekaligus dalam satu repositori dan mendorong masing-masing sesuai kebutuhannya
    Jika tidak punya kebutuhan seperti ini, mungkin Anda tidak akan merasakan nilai jj
  • Daya tarik jj bukan pada perintahnya, melainkan pada workflow yang intuitif
    Harus dicoba langsung untuk memahaminya
  • jj undo saja sudah cukup berharga
    Di git, sangat mudah masuk ke keadaan yang tidak bisa dipulihkan, sedangkan di jj bisa selesai hanya dengan beberapa kali undo

• Berkat jj, saya jadi lebih percaya diri memanfaatkan DAG non-linear
  Saya bebas menangani perubahan dengan banyak parent atau child
  Dulu saya memaksakan urutan secara tidak perlu, tetapi sekarang saya bisa mengekspresikan hubungan dependensi dengan jelas
  Proses review dan submit juga jauh lebih efisien

  • Saya penasaran apakah orang memakai workflow mega-merge + absorb di atas perubahan yang bercabang seperti ini